Re: On Windows, $old_archive_cmds uses `lib' to create static archives.

[Benoit Sigoure]

Quoting Ralf Wildenhues <address@hidden>:

> * Benoit Sigoure wrote on Sun, Apr 22, 2007 at 07:42:24PM CEST:
> > On Windows, when compiling with Visual C++, libtool seems to figure out
> > automagically that it has to create static archives with the `lib' command.
> [...]
> > I wonder how libtool figured this out and why libtool does this 
> > since it does
> > not support the Microsoft toolchain anyway.
>
> Yes, there are some patches floating around to change this, but they
> haven't been applied.

WRT Microsoft's toolchain?
But in the end, what's the point of doing this since there is no plan 
to provide
a real support for MSVC++? (AFAIK)

> > My question is: how can I override this behavior?  For instance, I 
> > can easily
> > use make CCLD=wrapper_script.sh but here, I have no control since it's
> > hardcoded in the libtool script.
>
> Which Libtool version do you use?  Plain or with any patches?

A stock ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)

> > I want to do this because I want to link everything with the 
> > /NODEFAULTLIB flag
> > without actually changing anything in the code I'm compiling.  And 
> > of course,
> > libtool won't let the `/NODEFAULTLIB' flag pass through.
>
> Not for $old_archive_cmds.  I guess we could add some flag here.
> (Want to suggest a patch? ;-)

Why not, but some people might not want to use this flag, so there has to be a
way to let it pass through (maybe with some other flags too).  Are you
suggesting that libtool ought to support MSVC++'s flags in its tough task of
argument filtering?

> Simplest workaround for you would be to put a shell script named
> `lib' early in your path that adds /NODEFAULTLIB (or simply adds
> an environment variable) to the command line, I guess.

Yeah, that's the workaround I use for now, but I wondered why libtool had this
hardcoded invokation of `lib'.

> > As a reminder, I use the Microsoft toolchain using lots of wrapper 
> > scripts so
> > that it appears to work transparantly just like GCC (this thread 
> > explains what
> > I did: http://lists.gnu.org/archive/html/libtool/2006-11/msg00046.html).
>
> Ah, ok.  So the workaround would fit right in your line of work, no?

Yes.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory