Problem with LT_PATH_NM

[Peter Kjellerstedt]

The other day I downloaded and tried to build the latest
version of stable glib (2.18.4) where they apparently had
switched from libtool 1.5.x to libtool 2.2.x. The build
failed with the following error:

libtool: link: link -dump -symbols  .libs/garray.o .libs/gasyncqueue.o 
.libs/gatomic.o .libs/gbacktrace.o .libs/gbase64.o .libs/gbookmarkfile.o 
.libs/gcache.o .libs/gchecksum.o .libs/gcompletion.o .libs/gconvert.o 
.libs/gdataset.o .libs/gdate.o .libs/gdir.o .libs/gerror.o .libs/gfileutils.o 
.libs/ghash.o .libs/ghook.o .libs/giochannel.o .libs/gkeyfile.o .libs/glist.o 
.libs/gmain.o .libs/gmappedfile.o .libs/gmarkup.o .libs/gmem.o 
.libs/gmessages.o .libs/gnode.o .libs/goption.o .libs/gpattern.o 
.libs/gprimes.o .libs/gqsort.o .libs/gqueue.o .libs/grel.o .libs/grand.o 
.libs/gregex.o .libs/gscanner.o .libs/gsequence.o .libs/gshell.o .libs/gslice.o 
.libs/gslist.o .libs/gstdio.o .libs/gstrfuncs.o .libs/gstring.o 
.libs/gtestutils.o .libs/gthread.o .libs/gthreadpool.o .libs/gtimer.o 
.libs/gtree.o .libs/guniprop.o .libs/gutf8.o .libs/gunibreak.o 
.libs/gunicollate.o .libs/gunidecomp.o .libs/gurifuncs.o .libs/gutils.o 
.libs/gprintf.o .libs/giounix.o .libs/gspawn.o   libcharset/.libs/libcharset.a 
gnulib/.libs/libgnulib.a pcre/.libs/libpcre.a |  | /bin/sed 's/.* //' | sort | 
uniq > .libs/libglib-2.0.exp
../libtool: eval: line 964: syntax error near unexpected token `|'

It is obvious that the error is the doubled "| |", which is
due to $global_symbol_pipe being empty. This in turn is due to
the fact that libtool has chosen "link -dump -symbols" as $NM...
This seemed extremely weird and after some searching I found 
the following difference in glib's aclocal.m4 between the 
1.5.x and 2.2.x version:

-# AC_PROG_NM
+
+# LT_PATH_NM
 # ----------
-# find the pathname to a BSD-compatible name lister
-AC_DEFUN([AC_PROG_NM],
-[AC_CACHE_CHECK([for BSD-compatible nm], lt_cv_path_NM,
+# find the pathname to a BSD- or MS-compatible name lister
+AC_DEFUN([LT_PATH_NM],
+[AC_REQUIRE([AC_PROG_CC])dnl
+AC_CACHE_CHECK([for BSD- or MS-compatible name lister (nm)], lt_cv_path_NM,
 [if test -n "$NM"; then
   # Let the user override the test.
   lt_cv_path_NM="$NM"
@@ -2669,16 +3263,51 @@
     done
     IFS="$lt_save_ifs"
   done
-  test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
+  : ${lt_cv_path_NM=no}
 fi])
+if test "$lt_cv_path_NM" != "no"; then
 NM="$lt_cv_path_NM"
-])# AC_PROG_NM
+else
+  # Didn't find any BSD compatible name lister, look for dumpbin.
+  AC_CHECK_TOOLS(DUMPBIN, ["dumpbin -symbols" "link -dump -symbols"], :)
+  AC_SUBST([DUMPBIN])
+  if test "$DUMPBIN" != ":"; then
+    NM="$DUMPBIN"
+  fi
+fi
+test -z "$NM" && NM=nm
+AC_SUBST([NM])
+_LT_DECL([], [NM], [1], [A BSD- or MS-compatible name lister])dnl
 
+AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_nm_interface],
+  [lt_cv_nm_interface="BSD nm"
+  echo "int some_variable = 0;" > conftest.$ac_ext
+  (eval echo "\"\$as_me:__oline__: $ac_compile\"" >&AS_MESSAGE_LOG_FD)
+  (eval "$ac_compile" 2>conftest.err)
+  cat conftest.err >&AS_MESSAGE_LOG_FD
+  (eval echo "\"\$as_me:__oline__: $NM \\\"conftest.$ac_objext\\\"\"" 
>&AS_MESSAGE_LOG_FD)
+  (eval "$NM \"conftest.$ac_objext\"" 2>conftest.err > conftest.out)
+  cat conftest.err >&AS_MESSAGE_LOG_FD
+  (eval echo "\"\$as_me:__oline__: output\"" >&AS_MESSAGE_LOG_FD)
+  cat conftest.out >&AS_MESSAGE_LOG_FD
+  if $GREP 'External.*some_variable' conftest.out > /dev/null; then
+    lt_cv_nm_interface="MS dumpbin"
+  fi
+  rm -f conftest*])
+])# LT_PATH_NM

As far as I understand it, the changes above are intended to find 
a name lister which works on Windows. However, my Linux Fedora Core 6 
computer has a /usr/bin/link which apparently triggers 
AC_CHECK_TOOLS into believing it can use "link -dump -symbols" 
even though it does not support those options (in fact it performs 
a symbolic link similar to ln...)

I would say that there are two bugs here: 
* the first is that the code looking for nm in 
  "$PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin" (not seen 
  in the patch above) is not doing its job. My $PATH contains 
  "...:/usr/bin:.." where nm is installed, but the for loop 
  does not split the colon separated $PATH correctly and thus 
  does not find /usr/bin/nm.
* the second is that my /usr/bin/link should not be used as NM
  since it obviously does not support the options required (as
  it is the wrong program).

I tried to look a libtool's git repository to see if there were
any changes related to this, but I could not find any (please
tell me if there are).

Thankfully I can use "NM=nm configure ..." to circumvent the 
problem, but this does not sound like a general solution.

//Peter