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

[Greg Chicares]

On 2017-08-20 18:14, Vadim Zeitlin wrote:
> On Sun, 20 Aug 2017 17:58:45 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> For the native builds distributed by MinGW-w64, invoking the
> GC> compiler with a fully-qualified path no longer works with
> GC> gcc-6.3.0:
> 
>  This is (almost) great timing as I've just spent half an hour on this
> myself and was just about to post here asking how did you manage to make
> this work.

The reason why you spent only half an hour on it is that you're
much faster than I am...

> GC> The compiler simply fails, returning "1" with no diagnostic.
> 
>  Because the C++ backend (libexec/gcc/i686-w64-mingw32/6.3.0/cc1plus.exe)
> can't find libwinpthread-1.dll which is in the directory of the driver
> (bin).

...as well as more insightful, whereas my approach is crude...

> GC> It succeeds only if the compiler's binary path is on $PATH:
> 
>  This is one solution. Another one would be to copy libwinpthread-1.dll to
> /opt/lmi/local/bin, just as is already done for a couple of other DLLs
> (i.e. update compiler_runtime_files make variable to include it). This
> seems to work too and seems less intrusive.

That's probably better than the experimental workaround I committed,
which I'm testing now by rebooting my VM and running

  $cd /tmp

  $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


which should finish in a little less than an hour.

>  In any case, I am reassured to know that this is not something specific to
> my Cygwin installation or configuration, so thanks for posting this.

Glad to hear it helped.