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

[Greg Chicares]

It's time to reopen this old thread, which begins in the archives here:
  http://lists.nongnu.org/archive/html/lmi/2017-08/msg00017.html

On 2017-08-20 17:58, Greg Chicares wrote:
> For the native builds distributed by MinGW-w64, invoking the
> compiler with a fully-qualified path no longer works with
> gcc-6.3.0:
> 
> /tmp[0]$cat hello.cpp
> #include <iostream>
> #include <ostream>
> 
> int main()
> {
>     std::cout << "Hello" << std::endl;
> }
> 
> /tmp[0]$PATH="/opt/lmi/local/bin:/opt/lmi/local/lib:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin"
>  /MinGW_/bin/g++ -c hello.cpp
> /tmp[1]$ls hello*
> hello.c  hello.cpp
> 
> The compiler simply fails, returning "1" with no diagnostic.
> It succeeds only if the compiler's binary path is on $PATH:
> 
> /tmp[0]$PATH="/opt/lmi/local/bin:/opt/lmi/local/lib:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/MinGW_/bin"
>  /MinGW_/bin/g++ -c hello.cpp
> /tmp[0]$ls hello*
> hello.c  hello.cpp  hello.o
> 
> This is of course regrettable: it makes it unreasonably
> difficult to use other compilers that might also provide
> binaries with names like 'cpp.exe'.
> 
> I'll push experimental
>   commit ffcea7f91b1af2fcb5514eba4870085273fe162c

That commit merely added the compiler's binary path to $PATH,
which was regrettable for the reason given above. Vadim replied:

http://lists.nongnu.org/archive/html/lmi/2017-08/msg00018.html

| 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.

and that's what I did in a06270feeb7973a7f1e0c2374de5fbb545e86bb6.

Vadim noted:

http://lists.nongnu.org/archive/html/lmi/2017-08/msg00042.html

| 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?

and I replied in this way:

http://lists.nongnu.org/archive/html/lmi/2017-08/msg00044.html

| 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.

which doesn't fully address the issue.

Now I want to...

https://lists.nongnu.org/archive/html/lmi/2019-04/msg00023.html

| Copy all required libraries as well as lmi's own binaries, so that
| each $INSTALL directory would have a complete set and there'd be no
| need to alter any path variable in the environment.

and I tried doing it this way:

---------8<--------8<--------8<--------8<--------8<--------8<--------8<-------
diff --git a/workhorse.make b/workhorse.make
index 79a30c5c..05145964 100644
--- a/workhorse.make
+++ b/workhorse.make
@@ -1043,12 +1043,15 @@ lmi_msw_res.o: lmi.ico
 
################################################################################
 
 # Install.
-
-# TODO ?? This line
-#   $(CP) --preserve --update $^
-# isn't quite right: running 'make install build_type=[...]' with
-# different build_types and picking the latest version of each
-# component can produce a mismatched set.
+#
+# Architecture-independent files are copied with 'cp --update'.
+# Architecture-dependent files are copied without '--update'.
+#
+# It may seem redundant to include $(compiler_runtime_files) in
+# $(installable_binaries), because the 'preinstall' target ought to
+# ensure that it's already in $(localbindir). However, $(wildcard)
+# expansion occurs when the makefile is read, before any prerequisite
+# target's recipe is executed.
 
 data_files := \
   $(wildcard $(addprefix $(srcdir)/,*.ico *.png *.xml *.xrc *.xsd *.xsl)) \
@@ -1056,10 +1059,17 @@ data_files := \
 help_files := \
   $(wildcard $(addprefix $(srcdir)/,*.html)) \
 
+installable_binaries := \
+  $(compiler_runtime_files) \
+  $(default_targets) \
+  $(wildcard $(localbindir)/*$(SHREXT)) \
+  $(wildcard $(locallibdir)/*$(SHREXT)) \
+  $(wildcard $(prefix)/third_party/bin/*$(EXEEXT)) \
+
 .PHONY: preinstall
 preinstall:
        @[ -z "$(compiler_runtime_files)" ] \
-         || $(CP) --preserve --update $(compiler_runtime_files) $(localbindir)
+         || $(CP) --preserve $(compiler_runtime_files) $(localbindir)
 
 .PHONY: install
 install: preinstall $(default_targets)
@@ -1068,7 +1078,7 @@ install: preinstall $(default_targets)
        address@hidden -d $(datadir)        ] || $(MKDIR) --parents $(datadir)
        address@hidden -d $(test_dir)       ] || $(MKDIR) --parents $(test_dir)
        address@hidden -d $(touchstone_dir) ] || $(MKDIR) --parents 
$(touchstone_dir)
-       @$(CP) --preserve --update $(default_targets) $(bindir)
+       @$(CP) --preserve $(installable_binaries) $(bindir)
        @$(CP) --preserve --update $(data_files) $(datadir)
        @$(CP) --preserve --update $(help_files) $(datadir)
        @datadir=$(datadir) srcdir=$(srcdir) $(srcdir)/mst_to_xst.sh
--------->8-------->8-------->8-------->8-------->8-------->8-------->8-------

but that results in:

$make install              
win32//libgcc_s_sjlj-1.dll 
/usr/lib/gcc/i686-w64-mingw32/7.3-win32//libstdc++-6.dll   
/opt/lmi/gcc/build/ship
cp: will not overwrite just-created '/opt/lmi/bin/libstdc++-6.dll' with 
'/opt/lmi/local/bin/libstdc++-6.dll'
cp: will not overwrite just-created '/opt/lmi/bin/libgcc_s_sjlj-1.dll' with 
'/opt/lmi/local/bin/libgcc_s_sjlj-1.dll'
make[1]: *** [/opt/lmi/src/lmi/workhorse.make:1081: install] Error 1
make: *** [GNUmakefile:217: /opt/lmi/gcc/build/ship] Error 2
make: Target 'install' not remade because of errors.

In order to support installation of any of various architectures
into the same /opt/lmi/bin/ directory, it's crucial not to use
'cp --update'. Reason: if 64-bit runtime files' datestamps are
later than those of their 32-bit analogues, then switching from
a 64- to a 32-bit installation would replace the 64-bit lmi
binaries but not the 64-bit compiler runtime files.

As the "It may seem redundant" comment explains, I fear a race
condition, and therefore copy the runtime files explicitly
in the 'install' recipe. That copying occurs immediately after
the 'preinstall' recipe copies the same files, hence the
"will not overwrite just-created" message.

Or so I think. Maybe I'm wrong about the race condition. But
I'm sure that this 'preinstall' thing is overwrought, so I'm
going to try a different approach instead:

(1) Revert a06270feeb and fix the problem in a better way: by
copying compiler runtime files to the _build_ directory whenever
it's entered. I'm assuming that no one ever enters that directory
directly, and everyone instead uses 'GNUmakefile" to enter it,
so that the invocation of that makefile's submakefile is a
single chokepoint through which all access to 'workhorse.make'
must pass.

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

IOW, I consider a06270feeb a poor fix, and it happened to
create an obstacle for the intended 'install' enhancement,
so I reverted and replaced it, then proceeded with the
enhancement. Of course, as always, I might have made it worse,
so careful review and testing are welcomed (pushing now).