jimzah/openafs
1
0
Fork 0
mirror of https://git.openafs.org/openafs.git synced 2025-01-18 15:00:12 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Avoid libtool 'nm' errors

Browse Source 
Starting around Solaris 11.3, '/usr/bin/nm -p' starts reporting some
symbols with the 'C' code. libtool cannot handle this (libtool bug
 #22373), which causes global_symbol_pipe in the generated libtool
script to be empty. This causes a rather confusing error when we go to
actually use libtool to link something ("syntax error near unexpected
token '|'"; see libtool bug #20947), and prevents the build from
continuing.

Address this in two ways:

For all Solaris 11 builds, default to /usr/sfw/bin/gnm over
/usr/bin/nm. This avoids any interop issues with libtool and nm, since
libtool of course works very well with GNU tooling.

In addition, try to catch any nm-related errors with libtool at
configure time, to provide a more helpful error message.

To implement these changes, create a wrapper around LT_INIT, called
AFS_LT_INIT.

Change-Id: I7d47c17f9d9401dc5dcc9676279bf1e4f53554c4
Reviewed-on: https://gerrit.openafs.org/12945
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
This commit is contained in:
Andrew Deason 2018-03-07 13:28:34 -06:00 committed by Benjamin Kaduk
parent 5a8b681531
commit 3e9ea61079
2 changed files with 31 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
configure.ac
View File

@ -19,7 +19,7 @@ AS_IF([test -z "$CFLAGS"], [CFLAGS=" "])
AC_USE_SYSTEM_EXTENSIONS
LT_INIT
AFS_LT_INIT
AC_PROG_CC
AC_PROG_LIBTOOL

30
src/cf/afs-libtool.m4 Normal file
View File

@ -0,0 +1,30 @@
dnl Change the default 'nm' in some situations
AC_DEFUN([AFS_LT_PATH_NM],
[AC_REQUIRE([AC_CANONICAL_HOST])
AS_CASE([$host_os],
dnl Starting around Solaris 11.3, the default 'nm' tool starts reporting
dnl symbols with the 'C' code when given '-p'. Libtool currently cannot deal
dnl with this, and it fails to figure out how to extract symbols from object
dnl files (see libtool bug #22373). To work around this, try to use the GNU nm
dnl instead by default, which is either always or almost always available.
dnl libtool, of course, works with that just fine.
[solaris2.11*],
[AS_IF([test x"$NM" = x && test -x /usr/sfw/bin/gnm],
[NM=/usr/sfw/bin/gnm])])])
dnl Our local wrapper around LT_INIT, to work around some bugs/limitations in
dnl libtool.
AC_DEFUN([AFS_LT_INIT],
[AC_REQUIRE([AFS_LT_PATH_NM])
LT_INIT
dnl If libtool cannot figure out how to extract symbol names from 'nm', then it
dnl will log a failure and lt_cv_sys_global_symbol_pipe will be unset, but it
dnl will not cause configure to bail out. Later on, when we try to link with
dnl libtool, it will cause a very confusing error message (see libtool bug
dnl #20947). To try and avoid that bad error message, try to catch that
dnl situation here, closer to when the error actually occurs.
AS_IF([test x"$lt_cv_sys_global_symbol_pipe" = x],
[AC_MSG_ERROR([libtool cannot figure out how to extract symbol names; look above for failures involving 'nm'])])])