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...) Cheers, Peter