Avoid libtool 'nm' errors
[openafs.git] / src / cf / afs-libtool.m4
1 dnl Change the default 'nm' in some situations
2 AC_DEFUN([AFS_LT_PATH_NM],
3   [AC_REQUIRE([AC_CANONICAL_HOST])
4    AS_CASE([$host_os],
5
6 dnl Starting around Solaris 11.3, the default 'nm' tool starts reporting
7 dnl symbols with the 'C' code when given '-p'. Libtool currently cannot deal
8 dnl with this, and it fails to figure out how to extract symbols from object
9 dnl files (see libtool bug #22373). To work around this, try to use the GNU nm
10 dnl instead by default, which is either always or almost always available.
11 dnl libtool, of course, works with that just fine.
12      [solaris2.11*],
13      [AS_IF([test x"$NM" = x && test -x /usr/sfw/bin/gnm],
14        [NM=/usr/sfw/bin/gnm])])])
15
16 dnl Our local wrapper around LT_INIT, to work around some bugs/limitations in
17 dnl libtool.
18 AC_DEFUN([AFS_LT_INIT],
19   [AC_REQUIRE([AFS_LT_PATH_NM])
20
21    LT_INIT
22
23 dnl If libtool cannot figure out how to extract symbol names from 'nm', then it
24 dnl will log a failure and lt_cv_sys_global_symbol_pipe will be unset, but it
25 dnl will not cause configure to bail out. Later on, when we try to link with
26 dnl libtool, it will cause a very confusing error message (see libtool bug
27 dnl #20947).  To try and avoid that bad error message, try to catch that
28 dnl situation here, closer to when the error actually occurs.
29    AS_IF([test x"$lt_cv_sys_global_symbol_pipe" = x],
30      [AC_MSG_ERROR([libtool cannot figure out how to extract symbol names; look above for failures involving 'nm'])])])