[autoconf-2.72|bash] Not able to detect MS dumpbin anymore

[Neumann-A]

Description / Steps to reproduce the issue

Try using NM='dumpbin.exe -symbols -headers' for configure

More analysis in microsoft/vcpkg#36706

Probably due to

-[m4_append_uniq([_AS_CLEANUP], [AS_REQUIRE([_AS_EMPTY_ELSE_PREPARE])])]dnl
-[else $as_nop
-  $1
+[else case e in @%:@(
+  e) $1 ;;
+esac

in autoconf but wasn't able to pin that to an upstream commit yet.

Expected behavior

Configure result of:

lt_cv_nm_interface='MS dumpbin

Actual behavior

Configure result of:

lt_cv_nm_interface='BSD nm'

(with all the errors that entails.)

Verification

• I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MSYS_NT-10.0-19045

Are you willing to submit a PR?

No response

[sskras]

Why close it?

[Neumann-A]

Why close it?

Because the shell is probably to blame somehow.
I don't currently know how to make it work again but it worked today until I ran a different shell script which then broke the detection again. I don't know why but somehow the line:
if $GREP 'External.*some_variable' conftest.out > /dev/null; then is not correctly interpreted.
Meaning that most likely the * is not passed verbatim to grep resulting in the failure.

[Neumann-A]

Ok I'll reopen it since it fails after a git pull of vcpkg so it has something to do with a msys change

[jeremyd2019]

It kind of sounds like the issue that required downgrading/keeping the msys2 grep package at an older version. Maybe some other grep is on the path, such as the one from MINGW-packages? (or since you are using vcpkg, maybe it pulls in some other grep entirely).

[Neumann-A]

I don't think it is related to grep since
$(AM_V_GEN)$(PYTHON) $(srcdir)/src/extensions.py $@.tmp '${XCBPROTO_XCBINCLUDEDIR}/*.xml'
in xcb-util-errors is also suddenly broken. From testing I observed that ${XCBPROTO_XCBINCLUDEDIR}/*.xml gets early expanded into one file in the folder instead of being passed on verbatim.

[Neumann-A]

Also configure reports the correct grep

[sskras]

It possibly would help if you report version of Bash (bash --version) and MSYS2 itself (uname -r).

[jeremyd2019]

$(AM_V_GEN)$(PYTHON) $(srcdir)/src/extensions.py $@.tmp '${XCBPROTO_XCBINCLUDEDIR}/*.xml' in xcb-util-errors is also suddenly broken.

I wonder if this could be more fallout from msys2/msys2-runtime#182, like msys2/msys2-runtime#187 and msys2/msys2-runtime#190. But this shouldn't affect an msys2 process (bash) calling another msys2 process (grep), it might affect that python example if it's calling a 'native' (mingw?) python rather than msys2 python

[Neumann-A]

uname -r = 3.4.10.x86_64

E:/vcpkg_cache/downloads/tools/msys2/52c8bb2635a5bae2/usr/bin/bash.exe --version
GNU bash, version 5.2.26(1)-release (x86_64-pc-msys)

But i have the feeling that it is a bug in the build scripts or something like this. The hwloc build for example has no problem.
here is the generated configure diff of gmp: configure.diff.txt

So what I did: I ran known working configure with broken msys without rerunning autoconf and it worked correctly. Then I took the generated configure from the broken msys and ran it with the known working msys and it broke. As such I conclude that the difference in the configure script is responsible for the detection error and as such it is an autotools regression.

[Neumann-A]

It probably boils down to changes in m4sh.m4. Is there an easy way to correctly regenerate the m4f files?