From: William M. Perry Date: Sat, 7 Nov 1998 07:49:23 +0000 (+0000) Subject: added some interesting suggestions X-Git-Tag: start~28 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a027404613afe12619522788f1562b99e0d20ef3;p=thirdparty%2Flibtool.git added some interesting suggestions --- diff --git a/mail/deplibs b/mail/deplibs index ec4b1b1dd..33a80fc6b 100644 --- a/mail/deplibs +++ b/mail/deplibs @@ -607,3 +607,298 @@ have succeeded (and the software we sell is such a case). 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 ; 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 ; 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" +Cc: Ian Lance Taylor , 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 +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 //\ 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 ; 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 ; 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 +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 + 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 ; 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 ; 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 ; 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" +Organization: Aethos Communication Systems ltd. +X-Mailer: Mozilla 4.5 [en] (WinNT; I) +X-Accept-Language: en +MIME-Version: 1.0 +To: Alexandre Oliva +CC: Ian Lance Taylor , 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> +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. +