Doug DeJulio | mailto:ddj@hks.net
HKS, Incorporated | http://www.hks.net/
+From gord@trick.fig.org Wed Nov 4 16:50 EDT 1998
+Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
+ by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id QAA12687
+ for <oliva@amazonas.dcc.unicamp.br>; Wed, 4 Nov 1998 16:50:18 -0200 (EDT)
+Received: from cabler.cableregina.com (ip2.net20483142.cr.sk.ca [204.83.142.2])
+ by grande.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id QAA03463
+ for <oliva@dcc.unicamp.br>; Wed, 4 Nov 1998 16:50:12 -0200 (EDT)
+Received: from [24.72.10.223] by cabler.cableregina.com
+ (SMTPD32-4.0) id A25C7D0074; Wed, 04 Nov 1998 12:52:12 -0600
+Received: (qmail 1392 invoked by uid 1001); 4 Nov 1998 18:51:16 -0000
+To: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
+Cc: Ian Lance Taylor <ian@cygnus.com>, tanner@gmx.de, oliva@dcc.unicamp.br,
+ bug-libtool@gnu.org
+Subject: Re: Inter-library dependencies in libtool
+References: <199811040125.UAA01678@subrogation.cygnus.com> <3640381C.725FC8F2@oranda.demon.co.uk>
+X-Attribution: Gord
+Mime-Version: 1.0 (generated by tm-edit 7.106)
+From: Gordon Matzigkeit <gord@trick.fig.org>
+Date: 04 Nov 1998 12:51:11 -0600
+In-Reply-To: "Gary V. Vaughan"'s message of Wed, 04 Nov 1998 11:18:52 +0000
+Message-ID: <86af27qokg.fsf@trick.fig.org>
+X-Mailer: Gnus v5.5/Emacs 20.2
+Content-Type: text/plain; charset=US-ASCII
+X-Content-Length: 2911
+Xref: araguaia.dcc.unicamp.br libtool-deplibs:6
+Lines: 80
+X-Gnus-Article-Number: 6 Thu Nov 5 08:41:15 1998
+
+Hi!
+
+>>>>> Gary V Vaughan writes:
+
+ GVV> Ian Lance Taylor wrote:
+
+ >> This kind of goes to the heart of libtool. libtool wants to
+ >> present a particular interface for using shared libraries.
+
+ GVV> Is that an "official" design goal?
+
+Yes. From the manual:
+
+ 1. The system must be as elegant as possible.
+
+The main power of libtool is that it blurs the distinction between
+static archives (`.a' files) and shared libraries, by providing an
+interface that unifies the two into a new beast, the `.la' file. This
+is the reason why libtool caught on: you can write Makefile rules that
+work for both shared and static libraries.
+
+ >> In order to do this, it assumes that the system supports certain
+ >> capabilities. One of those is that the system can support
+ >> undefined symbols in shared libraries.
+
+To add to this point: or the system can link shared libraries against
+one another (deplibs).
+
+ GVV> My understanding was that libtool wants to provide a single
+ GVV> interface for the building of shared libraries, particularly so
+ GVV> that a developer can use libtool in a Makefile (*without* all of
+ GVV> the system dependant rules that used to me necessary) and get
+ GVV> shared libraries on all of libtool's supported platforms using
+ GVV> the same build rules.
+
+Both your understandings are correct.
+
+ >> That means that on systems which do not permit shared libraries to
+ >> have undefined symbols--AIX and Windows--libtool doesn't really
+ >> work.
+
+I would state this somewhat differently: on those platforms, libtool
+works (it can still build static libraries), but it doesn't shine.
+
+ >> [[snip]] In other words, the interface which libtool presents is
+ >> deficient. It does not successfully hide the system on which it
+ >> is running, and it forces the code which calls libtool to make
+ >> adjustments.
+
+Exactly.
+
+I believe the correct way to solve this problem is to.... (drum roll)
+use inter-library dependencies!
+
+If `deplibs' is set, then the library has undefined symbols. If it
+isn't set, then we could assume it has no undefined symbols.
+
+So, using `-lanything' on the .la creation line would be a synonym for
+`-allow-undefined', and having no `-l' flags would be a synonym for
+`-no-undefined'.
+
+ >> Of course even that will not make Windows DLLs identical to ELF
+ >> shared libraries. ELF shared libraries permit the main program to
+ >> override a symbol in the shared library, and Windows DLLs do not.
+
+I'd just as soon cross that bridge when we come to it, unless you have
+any real-world examples that demand more control over whether or not
+DLLs are built.
+
+In any event, this is more incentive for Thomas Tanner's patches to
+restrict the symbol table, so that people don't get bitten by
+namespace clashes.
+
+Thanks for your comments,
+
+--
+ Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
+ Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
+
+From ian@cygnus.com Wed Nov 4 17:16 EDT 1998
+Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
+ by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA17371
+ for <oliva@amazonas.dcc.unicamp.br>; Wed, 4 Nov 1998 17:15:59 -0200 (EDT)
+Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1])
+ by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA04425
+ for <oliva@dcc.unicamp.br>; Wed, 4 Nov 1998 17:15:45 -0200 (EDT)
+Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
+ by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id OAA16598;
+ Wed, 4 Nov 1998 14:17:48 -0500 (EST)
+Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id OAA02450; Wed, 4 Nov 1998 14:17:48 -0500
+Date: Wed, 4 Nov 1998 14:17:48 -0500
+Message-Id: <199811041917.OAA02450@subrogation.cygnus.com>
+From: Ian Lance Taylor <ian@cygnus.com>
+To: gord@trick.fig.org
+CC: gvaughan@oranda.demon.co.uk, tanner@gmx.de, oliva@dcc.unicamp.br,
+ bug-libtool@gnu.org
+In-reply-to: <86af27qokg.fsf@trick.fig.org> (message from Gordon Matzigkeit on
+ 04 Nov 1998 12:51:11 -0600)
+Subject: Re: Inter-library dependencies in libtool
+X-Content-Length: 1774
+Xref: araguaia.dcc.unicamp.br libtool-deplibs:7
+Lines: 43
+X-Gnus-Article-Number: 7 Thu Nov 5 08:41:16 1998
+
+ From: Gordon Matzigkeit <gord@trick.fig.org>
+ Date: 04 Nov 1998 12:51:11 -0600
+
+ I believe the correct way to solve this problem is to.... (drum roll)
+ use inter-library dependencies!
+
+ If `deplibs' is set, then the library has undefined symbols. If it
+ isn't set, then we could assume it has no undefined symbols.
+
+ So, using `-lanything' on the .la creation line would be a synonym for
+ `-allow-undefined', and having no `-l' flags would be a synonym for
+ `-no-undefined'.
+
+This sounds reasonable. Of course, -allow-undefined should remain a
+possible option even if there are no -l options. I guess
+-no-undefined could be an error check, but it wouldn't have much
+functional use.
+
+ >> Of course even that will not make Windows DLLs identical to ELF
+ >> shared libraries. ELF shared libraries permit the main program to
+ >> override a symbol in the shared library, and Windows DLLs do not.
+
+ I'd just as soon cross that bridge when we come to it, unless you have
+ any real-world examples that demand more control over whether or not
+ DLLs are built.
+
+ In any event, this is more incentive for Thomas Tanner's patches to
+ restrict the symbol table, so that people don't get bitten by
+ namespace clashes.
+
+What I'm talking about is not namespace clashes, but rather the
+ability to override a particular function from a shared library. For
+example, I can write my own version of malloc and free, and libc.so on
+an ELF system will use them rather than the malloc and free linked
+into the library.
+
+I don't think there is anything libtool can do about this. It's
+something that is very useful when dealing with preexisting shared
+libraries, but is not particularly useful when dealing with shared
+libraries you build yourself.
+
+Ian
+
+From gord@mescaline.gnu.org Thu Nov 5 15:32 EDT 1998
+Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
+ by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id PAA10607
+ for <oliva@amazonas.dcc.unicamp.br>; Thu, 5 Nov 1998 15:32:00 -0200 (EDT)
+Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
+ by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id PAA22399
+ for <oliva@dcc.unicamp.br>; Thu, 5 Nov 1998 15:31:57 -0200 (EDT)
+Received: from hades.aethos.co.uk (hades.aethos.co.uk [195.171.18.1] (may be forged))
+ by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id MAA01615
+ for <bug-libtool@gnu.org>; Thu, 5 Nov 1998 12:37:11 -0500
+Received: from zeus.aethos.co.uk (zeus.aethos.co.uk [193.164.192.100])
+ by hades.aethos.co.uk (8.8.5/8.8.5) with ESMTP id RAA28242;
+ Thu, 5 Nov 1998 17:37:46 GMT
+Received: from oranda.demon.co.uk (samhain.aethos.co.uk [193.164.192.38]) by zeus.aethos.co.uk with ESMTP (8.7.1/8.7.1) id RAA03467; Thu, 5 Nov 1998 17:33:25 GMT
+Message-ID: <3641E0DF.A8F92E78@oranda.demon.co.uk>
+Date: Thu, 05 Nov 1998 17:31:11 +0000
+From: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
+Organization: Aethos Communication Systems ltd.
+X-Mailer: Mozilla 4.5 [en] (WinNT; I)
+X-Accept-Language: en
+MIME-Version: 1.0
+To: Alexandre Oliva <oliva@dcc.unicamp.br>
+CC: Ian Lance Taylor <ian@cygnus.com>, tanner@gmx.de, gord@trick.fig.org,
+ bug-libtool@gnu.org
+Subject: Re: Inter-library dependencies in libtool
+References: <199811041854.NAA02418@subrogation.cygnus.com> <364183EF.9F15E7D6@oranda.demon.co.uk> <orhfweny1t.fsf@araguaia.dcc.unicamp.br>
+Content-Transfer-Encoding: 7bit
+Content-Type: text/plain; charset=us-ascii
+X-Content-Length: 3787
+Xref: araguaia.dcc.unicamp.br libtool-deplibs:8
+Lines: 87
+X-Gnus-Article-Number: 8 Sat Nov 7 05:46:44 1998
+
+If I may be permitted to quote you gratuitously... I think there are two
+problems here, and solving the first will keep most people happy most of
+the time.
+
+In order of progressive difficulty...
+
+1. COMPILE TIME LTLIBRARIES
+***************************
+
+Alexandre Oliva wrote:
+>
+> [[1.1]] the programmer knows that his library is completely
+> self-contained, it does not depend on any external symbols
+> (-no-undefined)
+
+1.2) The link mode command line to libtool contains no -l options,
+ which implies your fallback method (try to link a shared library
+ as if `-no-undefined' had been specified, or if that fails build
+ only a static library).
+
+1.3) The programmer knows that resolving all of the symbols in his
+ library requires linking deplibs, and is able to specify all of
+ them on the link line (some if these may be installed .la files
+ which have deplibs of their own which libtool must also link
+ with).
+
+> [[1.4]] the programmer knows that there may be symbols in his library
+> that are going to be supplied by another library, which [[is]]
+> unknown in advance. If such dependencies exist, they have to
+> be resolved at program-linking time (-allow-undefined == default)
+
+ In the future maybe libtool will be able to do a two stage link
+ for platforms which can't do `-allow-undefined', the first link
+ to find which symbols are unresolved, the second against a
+ temporarily generated set of stubs... I'm not sure whether the
+ stage 2 lib can then resolve its stubbed functions against a
+ different library when it is subsequently linked into an
+ executable? Perhaps I am reiterating Ian's idea about stubbing
+ on broken platforms?
+
+ In the present, broken platforms will have to manage with static
+ libraries in this case.
+
+2. RUNTIME LTLIBRARIES
+**********************
+
+> [[2.1]] the programmer needs a library foo that is completely
+> self-contained, so that he can be sure that dlopen(foo) works,
+> and just adding -lfoo *after* the library is installed will be
+> fine (-self-contained ?)
+
+2.2) The programmer needs a library that can be dlopened, but which
+ can have all of its symbols resolved at link time with deplibs.
+ A small amount of magic in the form a .c and .h distributed with
+ libtool (as suggested by Gord) is enough to make sure deplibs
+ are dlopened if necessary and then the library itself is loaded.
+ At best, this will only be supported on platforms for which
+ libtool can generate shared libraries, perhaps only a (large)
+ subset of those.
+
+2.3) The programmer needs a library that can be dlopened, and
+ doesn't know at link time how all of the symbols will be resolved.
+ A (small) subset of the platforms for which libtool can generate
+ shared libraries, will be handled by the aforementioned magic.
+ For the unhandled cases dld will be required.
+
+> [[2.4]] although a library is not going to be self-contained,
+> [[snip]] the platform does not support libraries with undefined
+> symbols, a shared library is badly needed, [[This will]] require
+> dld.
+
+NOTE: in the above, I am assuming that
+ all-supported-platforms >= (large) >= (small) > no-platforms
+
+I don't see any need to add anymore command line switches, except
+perhaps to tell libtool whether this is a compile time or runtime
+library, but even that may prove unnecessary.
+
+The line between 1.3 and 1.4 could probably use some clarification; what
+if the link line includes several deplibs, but some symbols are
+still unresolved? 1.4? Maybe... what if the platform doesn't support
+`-no-undefined'? Perhaps there is a 1.3.5? In any case, for maximum
+portability, we want to keep the number of cases of 1.4 to a minimum.
+
+Cheers,
+ Gary.
+
projects / thirdparty / libtool.git / commitdiff
