libtool
[Top][All Lists]
Advanced

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

Re: somewhat misleading -no-undefined documentation


From: Peter Rosin
Subject: Re: somewhat misleading -no-undefined documentation
Date: Tue, 12 Oct 2010 12:23:01 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

Hi Simon,

Den 2010-10-12 11:19 skrev Simon Josefsson:
> Ralf Wildenhues <address@hidden> writes:
> 
>> I kinda like Simon's patch you referenced (wow, that's old!), so how
>> about this patch which takes from both your suggestions?
> 
> I like it.  Thanks, this closes a long-standing libtool concern of mine.
> 
> Generally, having to use -no-undefined to get things to work on some
> platforms (e.g., to get a working DLL) is somewhat obscure and seems
> counter to having the default behaviour Just Work.  Is there any reason
> -no-undefined cannot be the default?  Is it common for installed
> libraries to have unresolved symbols at link time?  Even if it is,
> couldn't libtool figure out that there aren't any external symbols, and
> create the DLL when it is possible?  I may be missing some details
> though.

-no-undefined predates my involvement and I have not done a decent
dig in the archives, but as far as I understand, the reasoning is
based on these facts:

1. There are legitimate reasons for libraries to have unresolved
   symbols.
2. Those libraries can't ever exist as (normal) DLLs.
3. However, they can exist as static libraries.
4. Libtool has no means to determine if the library has unresolved
   symbols as an intentional feature or if it's a bug.
5. It is a maintenance nightmare for Libtool to determine if the
   DLL failed to build because of unresolved symbols or for some
   other reason.  Or both.
6. A long time ago, it was determined that the default should be
   to not attempt to create DLLs unless it was known beforehand
   that there should be no unresolved symbols.

I can only assume that the reason for not attempting to build the
DLL is that there is no way to know if Libtool should fall back to
only creating a static library or if it should bomb out with an
error when the attempt to link the DLL fails.

Falling back to static and not error out when failing to build the
DLL has its problems, since even a big fat warning is easily missed
in the flood of messages in a typical build.

I assume that bombing out with an error will be a regression for
some libraries which currently relies on Libtool to not attempt the
creation of DLLs when -no-undefined is not issued.  Those projects
must be provided with a matching -undefined option for this to be
a viable path.  Or should it be -undefined-symbols? -undefined seems
so unspecific and, well, undefined...

Cheers,
Peter



reply via email to

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