Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

[Vadim Zeitlin]

On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn <address@hidden> wrote:

BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
BF> >
BF> > I.e. it created a shared library with undefined symbols without any
BF> > problems because it never actually passed -no-undefined to g++/ld.
BF> 
BF> In actual practice, it seems difficult or impossible to build programs 
BF> under systems like Linux with -no-undefined.

 I didn't know this but doesn't this make the situation even worse? I.e.
because of the above you can't even recommend people to use -no-undefined
by default. So the default behaviour will remain the current one, i.e. no
DLLs at all under Windows.

BF> > I have no idea whether -no-undefined is supposed to work like this but in
BF> > any case it seems to me that it's perfectly useless right now. It's not
BF> 
BF> Not quite useless, but not pedantically useful either.

 Useless and useful are subjective, of course, but what seems undeniably
objective to me is that currently libtool by default doesn't create shared
libraries under Windows at all, even with --disable-static (although,
again, --disable-static shouldn't be considered as a solution for this) and
you need to force it to do it by using -no-undefined explicitly. Moreover,
you may need to do this conditionally, for Windows only, as this could
break things under Linux apparently. And this drastically reduces libtool
usefulness under Windows.


 To put it in another way, currently libtool supposes that a shared library
has undefined symbols by default. There would be nothing intrinsically
wrong with this assumption but it results in clearly broken behaviour. So
IMO it must be changed. I think that ideally libtool should be capable of
determining on its own whether the library has undefined symbols or not.
But if/as this is too difficult to implement, for now a more reasonable
approach would be to admit that libtool doesn't know whether this is the
case and try to do its best with this information and try to create shared
libraries under Windows by default. If -no-undefined is explicitly
specified it wouldn't then change anything for its behaviour under Windows
and similar platforms (AIX?). Finally, some new -has-undefined option might
be introduced to explicitly tell libtool that a library really does have
unresolved external symbols and so can't be built under Windows.

 What do you think?
VZ

pgpD1ywJXMl_V.pgp
Description: PGP signature