]> git.ipfire.org Git - thirdparty/gcc.git/commit - libtool.m4
libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
authorNick Alcock <nick.alcock@oracle.com>
Fri, 3 Dec 2021 16:33:25 +0000 (16:33 +0000)
committerArsen Arsenović <arsen@gcc.gnu.org>
Mon, 7 Aug 2023 20:59:39 +0000 (22:59 +0200)
commitf330710912229678b65def1f6f52765baa3d0f7a
treece669b30b97a5494f146fbaa5f2dd763196fbf42
parentab422974567ae73926c2308c3400b5974d6e09f1
libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case

My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".

Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).

Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.

NM=my-nm now does a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM=/usr/bin/my-nm now avoids a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM="my-nm -p../wombat" now does a path search and runs e.g.
  /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm

NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
  ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm

This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)

Regenerate all affected configure scripts.

ChangeLog:

* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.

gcc/ChangeLog:

* configure: Regenerate.

libatomic/ChangeLog:

* configure: Regenerate.

libbacktrace/ChangeLog:

* configure: Regenerate.

libcc1/ChangeLog:

* configure: Regenerate.

libffi/ChangeLog:

* configure: Regenerate.

libgfortran/ChangeLog:

* configure: Regenerate.

libgm2/ChangeLog:

* configure: Regenerate.

libgomp/ChangeLog:

* configure: Regenerate.

libitm/ChangeLog:

* configure: Regenerate.

libobjc/ChangeLog:

* configure: Regenerate.

libphobos/ChangeLog:

* configure: Regenerate.

libquadmath/ChangeLog:

* configure: Regenerate.

libsanitizer/ChangeLog:

* configure: Regenerate.

libssp/ChangeLog:

* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.

libvtv/ChangeLog:

* configure: Regenerate.

lto-plugin/ChangeLog:

* configure: Regenerate.

zlib/ChangeLog:

* configure: Regenerate.
19 files changed:
gcc/configure
libatomic/configure
libbacktrace/configure
libcc1/configure
libffi/configure
libgfortran/configure
libgm2/configure
libgomp/configure
libitm/configure
libobjc/configure
libphobos/configure
libquadmath/configure
libsanitizer/configure
libssp/configure
libstdc++-v3/configure
libtool.m4
libvtv/configure
lto-plugin/configure
zlib/configure