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

[Greg Chicares]

On 2017-08-22 21:48, Greg Chicares wrote:
> On 2017-08-22 21:37, Vadim Zeitlin wrote:
>> On Tue, 22 Aug 2017 21:00:55 +0000 Greg Chicares <address@hidden> wrote:
>> 
>> GC> and it did work, but I've now reverted that and copied the
>> GC> pthread DLL to /opt/lmi/local/bin/ along with the compiler's
>> GC> other runtime files. We'd need to do that anyway for threaded
>> GC> code to work.
>> 
>>  One thing I realized after sending my message was that the DLLS in
>> compiler_runtime_files were only copied to a directory on the PATH during
>> "make install" -- but the files need to be compiled before installing them.
>> So, unless I'm missing something, this still shouldn't work on a completely
>> fresh installation and I think we need to execute "make once-only-setup" or
>> something like this from install_msw.sh, don't we?
> 
> Yes, we should do something like that, and we should also use wildcards
> for the DLL names because their suffixes may change in the future.

Pushed.

Indeed, the log from an initial attempt to 'make install' in a freshly-
created chroot says:

cp: cannot stat '/usr/lib/gcc/i686-w64-mingw32/4.9-win32/libstdc++-6.dll': No 
such file or directory
cp: cannot stat '/usr/lib/gcc/i686-w64-mingw32/4.9-win32/libgcc_s_sjlj-1.dll': 
No such file or directory
/opt/lmi/src/lmi/workhorse.make:889: recipe for target 'install' failed

but now that won't happen. Such a failure is still possible with a fresh
installation if one attempts to make a different target ('unit_tests',
e.g.) before 'install', but using 'install_msw.sh' precludes that.