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

[Vadim Zeitlin]

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.

 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.

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.

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.

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

 Regards,
VZ