]> sourceware.org Git - newlib-cygwin.git/commit
libtool.m4: fix nm BSD flag detection
authorNick Alcock <nick.alcock@oracle.com>
Mon, 27 Sep 2021 19:31:21 +0000 (20:31 +0100)
committerMike Frysinger <vapier@gentoo.org>
Wed, 12 Jan 2022 13:49:10 +0000 (08:49 -0500)
commit5ab7dd14e1123f481139ab83a7aedc6d0b2f5ce7
tree928b4f59aea356b4adbcbf06c3f019ee747b5388
parent4fe13b8d95dba46c05d6bd700e79ab8d503db0eb
libtool.m4: fix nm BSD flag detection

Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support.  Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:

 - it runs the test by doing an nm of /dev/null.  Some platforms
   reasonably refuse to do an nm on a device file, but before now this
   has only been worked around by assuming that the error message has a
   specific textual form emitted by Tru64 nm, and that getting this
   error means this is Tru64 nm and that nm -B would work to produce
   BSD-format output, even though the test never actually got anything
   but an error message out of nm -B.  This is fixable by nm'ing *nm
   itself* (since we necessarily have a path to it).

 - the test is entirely skipped if NM is set in the environment, on the
   grounds that the user has overridden the test: but the user cannot
   reasonably be expected to know that libtool wants not only nm but
   also flags forcing BSD-format output.  Worse yet, one such "user" is
   the top-level Cygnus configure script, which neither tests for
   nor specifies any BSD-format flags.  So platforms needing BSD-format
   flags always fail to set them when run in a Cygnus tree, breaking
   -export-symbols-regex on such platforms.  Libtool also needs to
   augment $LD on some platforms, but this is done unconditionally,
   augmenting whatever the user specified: the nm check should do the
   same.

   One wrinkle: if the user has overridden $NM, a path might have been
   provided: so we use the user-specified path if there was one, and
   otherwise do the path search as usual.  (If the nm specified doesn't
   work, this might lead to a few extra pointless path searches -- but
   the test is going to fail anyway, so that's not a problem.)

(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
*that* is a symlink to /usr/bin/nm.)

ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27967
* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
NM, if there is one.  Run nm on itself, not on /dev/null, to avoid
errors from nms that refuse to work on non-regular files.  Remove
other workarounds for this problem.  Strip out blank lines from the
nm output.
17 files changed:
libtool.m4
newlib/configure
newlib/iconvdata/configure
newlib/libc/configure
newlib/libc/machine/configure
newlib/libc/machine/i386/configure
newlib/libc/sys/configure
newlib/libc/sys/linux/configure
newlib/libc/sys/linux/linuxthreads/configure
newlib/libc/sys/linux/linuxthreads/machine/configure
newlib/libc/sys/linux/linuxthreads/machine/i386/configure
newlib/libc/sys/linux/machine/configure
newlib/libc/sys/linux/machine/i386/configure
newlib/libm/configure
newlib/libm/machine/configure
newlib/libm/machine/i386/configure
newlib/libm/machine/x86_64/configure
This page took 0.036982 seconds and 5 git commands to generate.