Hi! Here's another old thing sitting locally.
* Peter Ekberg wrote on Monday, August 15, 2005 22:35 CEST: > I wrote: > > Ralf Wildenhues wrote: > > > * Peter Ekberg wrote on Thu, Aug 11, 2005 at 11:38:59AM CEST: > > > m4/libtool.m4: > > > > > > | @@ -2840,7 +2946,8 @@ > > > | m4_require([_LT_DECL_EGREP])dnl > > > | > > > | # Check for command to grab the raw symbol name followed > > > by C symbol from nm. > > > | -AC_MSG_CHECKING([command to parse $NM output from > > > $compiler object]) > > > | +# $compiler is not yet set, fall back to $CC. > > > | +AC_MSG_CHECKING([command to parse $NM output from $CC object]) > > > | AC_CACHE_VAL([lt_cv_sys_global_symbol_pipe], > > > | [ > > > | # These are sane defaults that work on at least a few > > old systems. > > > > > > Why is this change needed? AFAICS, the output should be > identical. > > > > Hmmm, $compiler is empty if I "./configure CC=cl", but not if I > > just "./configure" or if I "./configure CC=gcc". Something is > > missing in the non-gcc case. > > Anyway, I'll drop that change, it is pure cosmetics... > > Crap, I mixed up a couple of trees. Facts are that for me $compiler > is empty in the above message in a clean checkout. If I look in > the generated configure script, $compiler is dereferenced before > the first compiler= assignment. > compiler=$CC is located in _LT_TAG_COMPILER, which is not required > by _LT_CMD_GLOBAL_SYMBOLS, and apparently nothing else that is > expanded before _LT_CMD_GLOBAL_SYMBOLS... > > How about adding > m4_require([_LT_TAG_COMPILER])dnl > at the end of the requirements for _LT_CMD_GLOBAL_SYMBOLS instead > of my previous feeble $CC attempt? > > (Just tested, works for me...) And here's the trivial patch in case that's what's holding this up: * libltdl/m4/libtool.m4 (_LT_CMD_GLOBAL_SYMBOLS): Require _LT_TAG_COMPILER to make sure that $compiler is assigned. Fixes crippled configure output. Cheers, Peter
head-assign-compiler.patch
Description: head-assign-compiler.patch