libtool
[Top][All Lists]
Advanced

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

Re[2]: libtool shouldn't switch to creating static library if it can't c


From: Vadim Zeitlin
Subject: Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
Date: Thu, 23 Jun 2011 14:25:25 +0200

On Thu, 23 Jun 2011 13:12:42 +0200 Peter Rosin <address@hidden> wrote:

PR> Den 2011-06-23 11:22 skrev Vadim Zeitlin:
PR> >  I have no idea whether -no-undefined is supposed to work like this but in
PR> > any case it seems to me that it's perfectly useless right now. It's not
PR> > checked at all under normal Unix systems so it can't be used to ensure 
that
PR> > a shared library actually doesn't have any undefined symbols and so could
PR> > be created under Windows too. And it must be always specified under
PR> > Windows as otherwise DLL are never created at all.
PR> 
PR> If you really are targeting Windows (or some other platform which needs
PR> -no-undefined to build libtool libraries) then you really do get a failure
PR> if there are undefined symbols.

 Yes but *only* if you had "-no-undefined" in your Makefile.am. If you do
not specify "-no-undefined", you practically silently (not quite as it does
output "libtool: link: warning: undefined symbols not allowed in $host
shared libraries" but this is very easy to miss) get a static library
instead, whether there are any undefined symbols or not.

 This is even worse than the original problem that I had because at least
you had a big fat warning with plenty of asterisks in that case because
there was another problem in that case. But if all goes perfectly well you
still never get a shared library without "no-undefined". Even if you
specified --disable-static as you did in my example (although IMO even
without it silently creating static library when a shared one was requested
is wrong). Am I the only one to think that this behaviour is singularly
unhelpful?

PR> Quoting the docs for the libtool -no-undefined option:
...
PR> I.e. no mention of any actual check if there were any undefined
PR> symbols.

 I agree that the current behaviour conforms to documentation. I just think
it's pretty bad and I dare say that I'm not alone to misunderstand it
because of expecting something useful from this option.

PR> However, I agree that it is awkward. If this was done today, with
PR> no backwards compatibility in mind, I'd say that -no-undefined should
PR> be the default and any packages that truly needed undefined symbols
PR> should somehow declare that instead, since that is more of a special
PR> case (IMHO). But it is as it is.

 I continue to believe that it's much worse than awkward under Windows.
Libtool should try to create DLLs there and fail if it doesn't work. Not
even trying is the worst possible solution.

 For me the ideal behaviour would be to try to link a DLL and stop with an
error if it doesn't work but according to the beginning of this thread,
this is not acceptable by default. So I can only propose:

1. At least do this when --disable-static is specified.
2. Try to link as DLL in any case (well, unless --disable-shared was used)
   and only fall back to static linking if it actually failed instead of
   giving up in advance just because -no-undefined wasn't used.

I probably could hack libtool to do (1) but I'm not sure I could do (2)
which is, IMHO, even more important.

 Any comments?
VZ

Attachment: pgpcIeM99G9aq.pgp
Description: PGP signature


reply via email to

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