Skip to content

Revert "Windows port: Work arount MSYS weirdness where it changes --libtool=…

Revert "Windows port: Work arount MSYS weirdness where it changes --libtool= command line arguments."

A very old version of MSYS performed normalization during path conversion so "/bin/sh ../../libtool" became "c:/opt/msys/1.0/bin/libtool" ("sh .." was considered a single folder), it doesn't do this any more; nor does MSYS2.

Also, the old comment was incorrect. It claimed: "This continues to reuse the LIBTOOL variable from automake if it's set, but works around some MSYS weirdness: When running g-ir-scanner, MSYS changes a command-line argument --libtool="/bin/sh ../../libtool" into --libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path because we already "know" where the libtool configure produced is."

.. yet the actual code was changed to: _gir_libtool = $(if (findstring MINGW,(shell uname -s)),--libtool="(top_builddir)/libtool",(if (LIBTOOL),--libtool="(LIBTOOL)"))

.. so in fact, if $(uname -s) contained "MINGW", then --libtool ignored the LIBTOOL variable from automake and used $(top_builddir)/libtool instead, at the very least, removing all trace of $(SHELL) from it.

Now that $(SHELL) has been re-introduced into libtool, it must not doubly appear in resolve_windows_libs in ccompiler.py, as otherwise sh.exe will try to execute sh.exe and that clearly will not work.

I've left some MSYS-specific hacks in dumper.py, some of which could probaly be removed safely now (execution through a temporary shell script), but I've opted to leave it as is for now.

This reverts commit 33bbdce1.

Merge request reports