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

[Greg Chicares]

On 2019-04-27 14:20, Vadim Zeitlin wrote:
> On Sat, 27 Apr 2019 00:05:25 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2019-04-26 21:29, Vadim Zeitlin wrote:
> [...]
> GC> >  Is this really a concern in practice? In the intervening years we've
> GC> > changed the compiler a couple of times and so I now have 3 or 4 of them 
> in
> GC> > my lmi VM, and it has never been a problem to set PATH appropriately 
> before
> GC> > using them. I.e. I'm simply not sure that there is an actual problem 
> here
> GC> > to begin with.
> GC> 
> GC> The 'cpp.exe' example is from actual experience: I had two compilers
> GC> that both had a C preprocessor with that exact name, and that caused
> GC> problems if I didn't change the order in which they occurred on the
> GC> global path when I wanted to switch between them.
> 
>  Right, if you have both directories on the global path, things may not
> work reliably. Which is why I never do this and, instead, I just run "make
> PATH=/path/for/compiler" without changing the global path. And this has
> always worked just fine without copying any DLLs for me.

I'd rue typing all those extra characters all the time. A compiler should
be able to find its own dependencies.

>  And, as I wrote in the previous reply, we could set the PATH appropriately
> automatically from GNUmakefile by adding it to MAKETARGET, which would be a
> nice improvement.

Agreed--done. I had to use make's 'export' to get this to work.

> GC> >  I do understand this goal, but I don't think we should include the DLLs
> GC> > needed only by the compiler and not by lmi itself in the list of 
> "required
> GC> > libraries".
> GC> 
> GC> But they are needed by lmi itself, at run time--otherwise:
> GC> 
> GC> $wine lmi_wx_shared
> GC> 016f:err:module:import_dll Library libstdc++-6.dll (which is needed by 
> L"Z:\\opt\\lmi\\bin\\lmi_wx_shared.exe") not found
> 
>  Sorry, I think there was a misunderstanding. I have absolutely no
> objections to or reservations about copying the DLLs needed by lmi itself
> to the installation directory, this is indeed the right thing to do. I was
> only speaking about the "DLLs needed **only** by the compiler", such as
> libwinpthread-1.dll which was added to compiler_runtime_files back in 2017
> by 2c593fa74. Copying this one there seems unnecessary, although, again,
> it's hardly a critical problem.

Is it still necessary? I.e., was that a transient MinGW-w64 defect,
affecting only whatever version we were using in 2017, or a permanent
one? AFAICT, it only ever affected the native compiler distributed by
the MinGW-w64 project, and never the debian cross-compiler, so I'd
have to try to install cygwin under wine to test it myself. Now that
multi-arch-ness is in trunk, can you test it with cygwin under msw?
It only takes twelve minutes here to do this:

cd /opt/lmi/src/lmi
make eviscerate
logfile=log-`date -u +'%Y%m%dT%H%MZ'`; echo "Log file is '$logfile.tar.bz2'."; \
./install_msw.sh >$logfile 2>&1; tar -cjf $logfile.tar.bz2 $logfile; mv 
${logfile}* ..

and it works with nothing special in the environment except
  PATH=/usr/bin:/bin:/usr/sbin:/sbin
i.e.
  unset LMI_HOST
  unset WINEPATH

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

I had to set $WINEPATH in 'msw_generic.make', in order to run targets
like 'cli_test', which run binaries in the build directory. Having
worked out how to set $WINEPATH in foo/multiarch, I didn't think it
was so bad to do it in that makefile--and I really didn't want to
make such test targets depend on 'install'.

>  Again, my only feebly objection is to copying the DLLs _not_ needed by
> lmi, but only needed by the compiler.

I wouldn't mind removing the pthread dll from that list of compiler
runtime files, as long as that doesn't break the build with cygwin.