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'])])])