libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MSYS+MSVC for libtool branch-2-0, take 7


From: Peter Ekberg
Subject: RE: MSYS+MSVC for libtool branch-2-0, take 7
Date: Mon, 15 Aug 2005 22:35:11 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]