Re: [lmi] MinGW-w64 gcc-6.3.0 anomaly

[Greg Chicares]

On 2019-04-26 21:29, Vadim Zeitlin wrote:
> On Fri, 26 Apr 2019 18:53:23 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> It's time to reopen this old thread, which begins in the archives here:
> GC>   http://lists.nongnu.org/archive/html/lmi/2017-08/msg00017.html
> 
>  Thanks for the context (here and in the parts I removed), it helps to
> understand the problem, but I'm not really certain what is our actual goal
> here. First of all:

The goal is to support multiple architectures and toolchains
(e.g., gcc-i686-w64-mingw32, clang-x86_64-pc-linux-gnu) so that:
several can coexist at the same time; switching among them is
easy and efficient; and any one we select works transparently
with the same commands we've grown accustomed to using.

We've explored many options, and this is the one I believe we've
agreed on, preferring it to
 - a script wrapper around each program we might want to run
 - a combination of environment variables
 - symlinks
 - typing commands like '/opt/lmi/gcc-i686-w64-mingw32/lmi...'
It's the worst way except for every other we've tried.

> GC> On 2017-08-20 17:58, Greg Chicares wrote:
> [...]
> GC> > The compiler simply fails, returning "1" with no diagnostic.
> GC> > It succeeds only if the compiler's binary path is on $PATH:
> [...]
> GC> > This is of course regrettable: it makes it unreasonably
> GC> > difficult to use other compilers that might also provide
> GC> > binaries with names like 'cpp.exe'.
> 
>  Is this really a concern in practice? In the intervening years we've
> changed the compiler a couple of times and so I now have 3 or 4 of them in
> my lmi VM, and it has never been a problem to set PATH appropriately before
> using them. I.e. I'm simply not sure that there is an actual problem here
> to begin with.

The 'cpp.exe' example is from actual experience: I had two compilers
that both had a C preprocessor with that exact name, and that caused
problems if I didn't change the order in which they occurred on the
global path when I wanted to switch between them.

And it's just plain wrong, philosophically, for
  /path/to/some_program
to require either
  PATH="/path/to/../somewhere:PATH"
globally or
  PATH="/path/to/../somewhere:PATH" /path/to/some_program
on each invocation--or (for the sake of completeness)
  cp /path/to/**/*.DLL $msw_system_directory
Unnecessary complexity is to be avoided.

> GC> Now I want to...
> GC> 
> GC> https://lists.nongnu.org/archive/html/lmi/2019-04/msg00023.html
> GC> 
> GC> | Copy all required libraries as well as lmi's own binaries, so that
> GC> | each $INSTALL directory would have a complete set and there'd be no
> GC> | need to alter any path variable in the environment.
> 
>  I do understand this goal, but I don't think we should include the DLLs
> needed only by the compiler and not by lmi itself in the list of "required
> libraries".

But they are needed by lmi itself, at run time--otherwise:

$wine lmi_wx_shared
016f:err:module:import_dll Library libstdc++-6.dll (which is needed by 
L"Z:\\opt\\lmi\\bin\\lmi_wx_shared.exe") not found

> GC> (1) Revert a06270feeb and fix the problem in a better way: by
> GC> copying compiler runtime files to the build directory whenever
> GC> it's entered. I'm assuming that no one ever enters that directory
> GC> directly, and everyone instead uses 'GNUmakefile" to enter it,
> 
>  I did execute commands directly in this directory when I wanted to specify
> some make flags that couldn't be easily passed through the main GNUmakefile
> but it's a special case and I could just set the PATH directory anyhow,
> i.e. it's not really an objection.

I believe even that will work as long as you first run 'make'
in any way that causes it to invoke its submakefile--even
something trivial like
  make eraseme.policy
whereas, before this change, you'd need to do
  make install
to get the compiler runtime files copied.

> GC> (2) Copy the compiler runtime files directly from their origin,
> GC> in the 'install' target, as before a06270feeb was committed.
> 
>  Why not.

Advantages:

(A) If we don't, then attempting to run lmi produces:
  016f:err:module:import_dll Library libstdc++-6.dll (which is needed by 
L"Z:\\opt\\lmi\\bin\\lmi_wx_shared.exe") not found
as explained above.

(B) Now I can do this:
  /opt/lmi/bin[0]$unset WINEPATH
  /opt/lmi/bin[0]$wine lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data       
                 
and it works. I've wasted quite a few hours wrestling with $WINEPATH
over the last couple of years. Now I never have to mess with it again.
Ura! Ura! Ura!

Disadvantage: Copies cost slightly more than zero. We could almost
eliminate the cost by using 'cp --link'. I'm not considering that now
because I need to freeze new features until I get that branch merged.

> GC> IOW, I consider a06270feeb a poor fix, and it happened to
> GC> create an obstacle for the intended 'install' enhancement,
> GC> so I reverted and replaced it, then proceeded with the
> GC> enhancement. Of course, as always, I might have made it worse,
> GC> so careful review and testing are welcomed (pushing now).
> 
>  I don't think you made anything worse, but I'm not sure what has become
> significantly better neither.

In trunk, we can dispense with $WINEPATH altogether.

In odd/multiarch, we can achieve our goal in the least awful way.