| blob | a298728f0f1ea63979db4a62cd37912eaf11bbcc |
1 From nobody Wed Oct 14 16:45:01 1998
2 X-From-Line: ian@cygnus.com Fri Apr 17 23:33:18 1998
3 Return-Path: <ian@cygnus.com>
4 Delivered-To: gord@trick.profitpress.com
5 Received: (qmail 23427 invoked from network); 17 Apr 1998 23:33:17 -0000
6 Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
7 by 127.0.0.1 with SMTP; 17 Apr 1998 23:33:17 -0000
8 Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id OAA06912 for <gord@profitpress.com>; Fri, 17 Apr 1998 14:17:39 -0600
9 Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
10 by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id QAA18613;
11 Fri, 17 Apr 1998 16:18:12 -0400 (EDT)
12 Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id QAA08387; Fri, 17 Apr 1998 16:18:11 -0400
13 Date: Fri, 17 Apr 1998 16:18:11 -0400
14 Message-Id: <199804172018.QAA08387@subrogation.cygnus.com>
15 From: Ian Lance Taylor <ian@cygnus.com>
16 To: gord@profitpress.com
17 CC: bug-libtool@gnu.org
18 In-reply-to: <86k98oh6fy.fsf@trick.profitpress.com> (message from Gordon
19 Matzigkeit on 17 Apr 1998 08:24:33 -0600)
20 Subject: Re: libtool on cygwin32
21 Xref: trick.profitpress.com mail.libtool:1335
22 Lines: 30
23 X-Gnus-Article-Number: 2 Mon Nov 2 17:17:55 1998
25 From: Gordon Matzigkeit <gord@profitpress.com>
26 Date: 17 Apr 1998 08:24:33 -0600
28 >>>>> Ian Lance Taylor writes:
30 [...]
32 ILT> So, my choices are to use -no-undefined -lbfd everywhere, or to
33 ILT> use it only on Windows.
35 Would `-avoid-deps' (a proposed flag) give you what you want?
37 default = record inter-library dependencies on all platforms, if
38 possible.
40 -no-undefined = the dependency info provided is complete. Build
41 shared libraries on AIX and windows.
43 -avoid-deps = implies `-no-undefined'. However, avoid recording
44 inter-library dependencies unless they are required for building a
45 shared library.
47 Yes, that sounds like it will do what I need.
49 Somebody someday may want to record some library dependencies but not
50 others, in which case you would want
51 -avoid-deps -lfoo -no-avoid-deps -lbar
53 Ian
55 From nobody Wed Oct 14 16:45:40 1998
56 X-From-Line: ian@cygnus.com Mon Apr 27 16:24:19 1998
57 Return-Path: <ian@cygnus.com>
58 Delivered-To: gord@trick.profitpress.com
59 Received: (qmail 136 invoked from network); 27 Apr 1998 16:24:18 -0000
60 Received: from unknown (HELO bambam.m-tech.ab.ca) (127.0.0.1)
61 by localhost with SMTP; 27 Apr 1998 16:24:18 -0000
62 Received: from tweedledumb.cygnus.com (gateway.m-tech.ab.ca [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id JAA21924 for <gord@m-tech.ab.ca>; Mon, 27 Apr 1998 09:42:43 -0600
63 Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
64 by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id LAA02934;
65 Mon, 27 Apr 1998 11:48:04 -0400 (EDT)
66 Received: (ian@localhost) by subrogation.cygnus.com (950413.SGI.8.6.12/8.6.4) id LAA01776; Mon, 27 Apr 1998 11:48:03 -0400
67 Date: Mon, 27 Apr 1998 11:48:03 -0400
68 Message-Id: <199804271548.LAA01776@subrogation.cygnus.com>
69 From: Ian Lance Taylor <ian@cygnus.com>
70 To: gord@m-tech.ab.ca
71 CC: robbe@orcus.priv.at, bug-libtool@gnu.org
72 In-reply-to: <86bttpvbqd.fsf@trick.profitpress.com> (message from Gordon
73 Matzigkeit on 25 Apr 1998 15:21:30 -0600)
74 Subject: Re: libtool 1.2: Why no inter-lib dependencies on ELF?
75 Xref: trick.profitpress.com mail.libtool:1388
76 Lines: 27
77 X-Gnus-Article-Number: 3 Mon Nov 2 17:17:55 1998
79 From: Gordon Matzigkeit <gord@m-tech.ab.ca>
80 Date: 25 Apr 1998 15:21:30 -0600
82 There are still some unresolved issues (see
83 http://www.profitpress.com/libtool/deplibs.html). Full inter-library
84 dependency support is scheduled for libtool 1.3, though, and should
85 appear in the next beta-testing release.
87 I read that page, and here are a few quick notes.
89 1) On any platform which does not require -fpic you can link
90 static libraries into shared libraries. These platforms include
91 AIX, Irix 5/6, and Windows.
93 2) On any functioning ELF platform you can include code which was not
94 compiled with -fpic in a shared library, and you can link with a
95 static library when creating a shared library. You say that Solaris
96 won't let you link a shared library against a static one, but it
97 appears to work for me. What type of test are you using?
99 3) On SunOS you can not correctly link a static library into a shared
100 library. It will mostly work, but I believe that certain operations,
101 such as overriding a shared library function in the main executable,
102 will fail.
104 Ian
106 From nobody Wed Oct 14 16:48:43 1998
107 X-From-Line: gord@gnu.org Thu Sep 10 04:39:20 1998
108 Return-Path: <gord@gnu.org>
109 Delivered-To: gord@trick.fig.org
110 Received: (qmail 30644 invoked from network); 10 Sep 1998 04:39:18 -0000
111 Received: from gen2-93ip34.cadvision.com (HELO bambam.m-tech.ab.ca) (209.91.93.34)
112 by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 10 Sep 1998 04:39:18 -0000
113 Received: from mescaline.gnu.org (gateway [10.0.0.1]) by bambam.m-tech.ab.ca (8.8.5/8.6.9) with ESMTP id WAA26741 for <gord@m-tech.ab.ca>; Wed, 9 Sep 1998 22:38:15 -0600
114 Received: from mailhost.cyberramp.net (root@mailhost.cyberramp.net [207.158.64.11]) by mescaline.gnu.org (8.8.5/8.6.12GNU) with ESMTP id AAA11165 for <bug-libtool@gnu.org>; Thu, 10 Sep 1998 00:38:17 -0400
115 Received: from fuzzylog.simple.dallas.tx.us (dal-tsa11-49.cyberramp.net [207.158.111.49])
116 by mailhost.cyberramp.net (8.9.1a/8.9.1/ler-980825-0832-PM) with ESMTP id XAA13581;
117 Wed, 9 Sep 1998 23:37:41 -0500 (CDT)
118 Received: from scooby (scooby [192.168.1.3])
119 by fuzzylog.simple.dallas.tx.us (8.8.8/8.8.8) with SMTP id XAA27692;
120 Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
121 Date: Wed, 9 Sep 1998 23:37:38 -0500 (CDT)
122 From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
123 To: Libtool Bugs <bug-libtool@gnu.org>
124 Subject: Late-binding looses space efficiency ...
125 Message-ID: <Pine.SO4.4.02.9809092322490.808-100000@scooby.simple.dallas.tx.us>
126 MIME-Version: 1.0
127 Content-Type: TEXT/PLAIN; charset=US-ASCII
128 Xref: trick.fig.org libtool:1605
129 Lines: 27
130 X-Gnus-Article-Number: 4 Mon Nov 2 17:17:55 1998
132 On most systems, libtool does not supply the dependency libraries (-llib) when
133 it creates the shared library in spite of these being supplied on the libtool
134 command line. The ImageMagick package uses quite a few dependency libraries.
135 The ImageMagick library uses these libraries directly but utilities built
136 using the ImageMagick library only link against these libraries because the
137 ImageMagick library demands it.
139 Through testing we have found that if the 'ltconfig' archive_cmds definition
140 is ammended to include $deplibs that linked programs become much smaller (1/3
141 to 1/4 the original size). This appears to be because more code is included
142 in the shared library itself, avoiding the need for this to be part of the
143 program.
145 The distributed 'ltconfig' only supplies $deplibs for systems matching osf3* |
146 osf4*. Is there a reason why $deplibs is not supplied for all systems that can
147 support inter-library dependencies? Reducing overall package size is highly
148 desireable in order to reduce disk-space consumption and binary distribution
149 size.
151 Thanks,
153 Bob
154 ======================================
155 Bob Friesenhahn
156 bfriesen@simple.dallas.tx.us
157 http://www.cyberramp.net/~bfriesen
159 From nobody Wed Oct 14 16:52:40 1998
160 X-From-Line: ddj@hks.net Thu Sep 17 21:29:13 1998
161 Return-Path: <ddj@hks.net>
162 Delivered-To: gord@trick.fig.org
163 Received: (qmail 22994 invoked by uid 1003); 17 Sep 1998 21:29:12 -0000
164 Delivered-To: jana-profitpress-gord@profitpress.com
165 Received: (qmail 22991 invoked from network); 17 Sep 1998 21:29:11 -0000
166 Received: from dali.hks.net (ddj@208.203.175.210)
167 by cs366707-a.cgmo1.ab.wave.home.com with SMTP; 17 Sep 1998 21:29:11 -0000
168 Received: (from ddj@localhost)
169 by dali.hks.net (8.8.5/8.8.5) id RAA04020;
170 Thu, 17 Sep 1998 17:26:28 -0400
171 Received: from BatMail.robin.v2.15.CUILIB.3.45.SNAP.NOT.LINKED.dali..none..ix86.Linux
172 via MS.5.6.dali.(none).ix86_Linux;
173 Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
174 Message-ID: <oq0Lu3Jz000185PkIG@hks.net>
175 Date: Thu, 17 Sep 1998 17:26:27 -0400 (EDT)
176 From: Doug DeJulio <ddj@hks.net>
177 To: gord@profitpress.com
178 Subject: Re: Libtool Inter-library Dependencies
179 Xref: trick.fig.org libtool:1611
180 Lines: 32
181 X-Gnus-Article-Number: 5 Mon Nov 2 17:17:55 1998
183 I read your discussion of why libtool can't handle inter-library
184 dependencies and how people might be able to help fix this. I found
185 an error in item #1 of "The Solution". I quote:
187 > Finally, there are some systems which won't even allow you to link a
188 > shared library against a static one:
189 > Solaris 2.x
191 This is only true in most cases. If all of the accessed individual
192 object files in the static library *could* have been put in a shared
193 library, things will work just fine. It's not the type of library
194 that matters, but the type of object files.
196 Our commercial product includes a library and a few
197 dynamically-loadable modules that make that library accessible to
198 various interpretetd languages (TCL, Perl, PHP3 and Python at the
199 moment, with more coming). We don't distribute a shared library
200 anymore because when we did this caused a ton of trouble (most people
201 just couldn't get it configured correctly). I haven't yet found a
202 platform on which linking dynamically-loadable object file against a
203 static "ar" archive containing relocatable object files causes any
204 trouble (and we support SCO, Digital Unix, SCO, Solaris, Linux, and
205 FreeBSD, so this isn't because of narrow experience).
207 So, the main point is that just deciding whether it'll work based on
208 looking at the library file will in some cases fail when it should
209 have succeeded (and the software we sell is such a case).
211 --
212 Doug DeJulio | mailto:ddj@hks.net
213 HKS, Incorporated | http://www.hks.net/
215 From gord@trick.fig.org Wed Nov 4 16:50 EDT 1998
216 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
217 by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id QAA12687
218 for <oliva@amazonas.dcc.unicamp.br>; Wed, 4 Nov 1998 16:50:18 -0200 (EDT)
219 Received: from cabler.cableregina.com (ip2.net20483142.cr.sk.ca [204.83.142.2])
220 by grande.dcc.unicamp.br (8.8.5/8.8.5) with SMTP id QAA03463
221 for <oliva@dcc.unicamp.br>; Wed, 4 Nov 1998 16:50:12 -0200 (EDT)
222 Received: from [24.72.10.223] by cabler.cableregina.com
223 (SMTPD32-4.0) id A25C7D0074; Wed, 04 Nov 1998 12:52:12 -0600
224 Received: (qmail 1392 invoked by uid 1001); 4 Nov 1998 18:51:16 -0000
225 To: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
226 Cc: Ian Lance Taylor <ian@cygnus.com>, tanner@gmx.de, oliva@dcc.unicamp.br,
227 bug-libtool@gnu.org
228 Subject: Re: Inter-library dependencies in libtool
229 References: <199811040125.UAA01678@subrogation.cygnus.com> <3640381C.725FC8F2@oranda.demon.co.uk>
230 X-Attribution: Gord
231 Mime-Version: 1.0 (generated by tm-edit 7.106)
232 From: Gordon Matzigkeit <gord@trick.fig.org>
233 Date: 04 Nov 1998 12:51:11 -0600
234 In-Reply-To: "Gary V. Vaughan"'s message of Wed, 04 Nov 1998 11:18:52 +0000
235 Message-ID: <86af27qokg.fsf@trick.fig.org>
236 X-Mailer: Gnus v5.5/Emacs 20.2
237 Content-Type: text/plain; charset=US-ASCII
238 X-Content-Length: 2911
239 Xref: araguaia.dcc.unicamp.br libtool-deplibs:6
240 Lines: 80
241 X-Gnus-Article-Number: 6 Thu Nov 5 08:41:15 1998
243 Hi!
245 >>>>> Gary V Vaughan writes:
247 GVV> Ian Lance Taylor wrote:
249 >> This kind of goes to the heart of libtool. libtool wants to
250 >> present a particular interface for using shared libraries.
252 GVV> Is that an "official" design goal?
254 Yes. From the manual:
256 1. The system must be as elegant as possible.
258 The main power of libtool is that it blurs the distinction between
259 static archives (`.a' files) and shared libraries, by providing an
260 interface that unifies the two into a new beast, the `.la' file. This
261 is the reason why libtool caught on: you can write Makefile rules that
262 work for both shared and static libraries.
264 >> In order to do this, it assumes that the system supports certain
265 >> capabilities. One of those is that the system can support
266 >> undefined symbols in shared libraries.
268 To add to this point: or the system can link shared libraries against
269 one another (deplibs).
271 GVV> My understanding was that libtool wants to provide a single
272 GVV> interface for the building of shared libraries, particularly so
273 GVV> that a developer can use libtool in a Makefile (*without* all of
274 GVV> the system dependant rules that used to me necessary) and get
275 GVV> shared libraries on all of libtool's supported platforms using
276 GVV> the same build rules.
278 Both your understandings are correct.
280 >> That means that on systems which do not permit shared libraries to
281 >> have undefined symbols--AIX and Windows--libtool doesn't really
282 >> work.
284 I would state this somewhat differently: on those platforms, libtool
285 works (it can still build static libraries), but it doesn't shine.
287 >> [[snip]] In other words, the interface which libtool presents is
288 >> deficient. It does not successfully hide the system on which it
289 >> is running, and it forces the code which calls libtool to make
290 >> adjustments.
292 Exactly.
294 I believe the correct way to solve this problem is to.... (drum roll)
295 use inter-library dependencies!
297 If `deplibs' is set, then the library has undefined symbols. If it
298 isn't set, then we could assume it has no undefined symbols.
300 So, using `-lanything' on the .la creation line would be a synonym for
301 `-allow-undefined', and having no `-l' flags would be a synonym for
302 `-no-undefined'.
304 >> Of course even that will not make Windows DLLs identical to ELF
305 >> shared libraries. ELF shared libraries permit the main program to
306 >> override a symbol in the shared library, and Windows DLLs do not.
308 I'd just as soon cross that bridge when we come to it, unless you have
309 any real-world examples that demand more control over whether or not
310 DLLs are built.
312 In any event, this is more incentive for Thomas Tanner's patches to
313 restrict the symbol table, so that people don't get bitten by
314 namespace clashes.
316 Thanks for your comments,
318 --
319 Gordon Matzigkeit <gord@fig.org> //\ I'm a FIG (http://www.fig.org/)
320 Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/)
322 From ian@cygnus.com Wed Nov 4 17:16 EDT 1998
323 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
324 by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA17371
325 for <oliva@amazonas.dcc.unicamp.br>; Wed, 4 Nov 1998 17:15:59 -0200 (EDT)
326 Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1])
327 by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id RAA04425
328 for <oliva@dcc.unicamp.br>; Wed, 4 Nov 1998 17:15:45 -0200 (EDT)
329 Received: from subrogation.cygnus.com (subrogation.cygnus.com [192.80.44.76])
330 by tweedledumb.cygnus.com (8.8.5/8.8.5) with ESMTP id OAA16598;
331 Wed, 4 Nov 1998 14:17:48 -0500 (EST)
332 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
333 Date: Wed, 4 Nov 1998 14:17:48 -0500
334 Message-Id: <199811041917.OAA02450@subrogation.cygnus.com>
335 From: Ian Lance Taylor <ian@cygnus.com>
336 To: gord@trick.fig.org
337 CC: gvaughan@oranda.demon.co.uk, tanner@gmx.de, oliva@dcc.unicamp.br,
338 bug-libtool@gnu.org
339 In-reply-to: <86af27qokg.fsf@trick.fig.org> (message from Gordon Matzigkeit on
340 04 Nov 1998 12:51:11 -0600)
341 Subject: Re: Inter-library dependencies in libtool
342 X-Content-Length: 1774
343 Xref: araguaia.dcc.unicamp.br libtool-deplibs:7
344 Lines: 43
345 X-Gnus-Article-Number: 7 Thu Nov 5 08:41:16 1998
347 From: Gordon Matzigkeit <gord@trick.fig.org>
348 Date: 04 Nov 1998 12:51:11 -0600
350 I believe the correct way to solve this problem is to.... (drum roll)
351 use inter-library dependencies!
353 If `deplibs' is set, then the library has undefined symbols. If it
354 isn't set, then we could assume it has no undefined symbols.
356 So, using `-lanything' on the .la creation line would be a synonym for
357 `-allow-undefined', and having no `-l' flags would be a synonym for
358 `-no-undefined'.
360 This sounds reasonable. Of course, -allow-undefined should remain a
361 possible option even if there are no -l options. I guess
362 -no-undefined could be an error check, but it wouldn't have much
363 functional use.
365 >> Of course even that will not make Windows DLLs identical to ELF
366 >> shared libraries. ELF shared libraries permit the main program to
367 >> override a symbol in the shared library, and Windows DLLs do not.
369 I'd just as soon cross that bridge when we come to it, unless you have
370 any real-world examples that demand more control over whether or not
371 DLLs are built.
373 In any event, this is more incentive for Thomas Tanner's patches to
374 restrict the symbol table, so that people don't get bitten by
375 namespace clashes.
377 What I'm talking about is not namespace clashes, but rather the
378 ability to override a particular function from a shared library. For
379 example, I can write my own version of malloc and free, and libc.so on
380 an ELF system will use them rather than the malloc and free linked
381 into the library.
383 I don't think there is anything libtool can do about this. It's
384 something that is very useful when dealing with preexisting shared
385 libraries, but is not particularly useful when dealing with shared
386 libraries you build yourself.
388 Ian
390 From gord@mescaline.gnu.org Thu Nov 5 15:32 EDT 1998
391 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
392 by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id PAA10607
393 for <oliva@amazonas.dcc.unicamp.br>; Thu, 5 Nov 1998 15:32:00 -0200 (EDT)
394 Received: from mescaline.gnu.org (mescaline.gnu.org [158.121.106.21])
395 by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id PAA22399
396 for <oliva@dcc.unicamp.br>; Thu, 5 Nov 1998 15:31:57 -0200 (EDT)
397 Received: from hades.aethos.co.uk (hades.aethos.co.uk [195.171.18.1] (may be forged))
398 by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id MAA01615
399 for <bug-libtool@gnu.org>; Thu, 5 Nov 1998 12:37:11 -0500
400 Received: from zeus.aethos.co.uk (zeus.aethos.co.uk [193.164.192.100])
401 by hades.aethos.co.uk (8.8.5/8.8.5) with ESMTP id RAA28242;
402 Thu, 5 Nov 1998 17:37:46 GMT
403 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
404 Message-ID: <3641E0DF.A8F92E78@oranda.demon.co.uk>
405 Date: Thu, 05 Nov 1998 17:31:11 +0000
406 From: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
407 Organization: Aethos Communication Systems ltd.
408 X-Mailer: Mozilla 4.5 [en] (WinNT; I)
409 X-Accept-Language: en
410 MIME-Version: 1.0
411 To: Alexandre Oliva <oliva@dcc.unicamp.br>
412 CC: Ian Lance Taylor <ian@cygnus.com>, tanner@gmx.de, gord@trick.fig.org,
413 bug-libtool@gnu.org
414 Subject: Re: Inter-library dependencies in libtool
415 References: <199811041854.NAA02418@subrogation.cygnus.com> <364183EF.9F15E7D6@oranda.demon.co.uk> <orhfweny1t.fsf@araguaia.dcc.unicamp.br>
416 Content-Transfer-Encoding: 7bit
417 Content-Type: text/plain; charset=us-ascii
418 X-Content-Length: 3787
419 Xref: araguaia.dcc.unicamp.br libtool-deplibs:8
420 Lines: 87
421 X-Gnus-Article-Number: 8 Sat Nov 7 05:46:44 1998
423 If I may be permitted to quote you gratuitously... I think there are two
424 problems here, and solving the first will keep most people happy most of
425 the time.
427 In order of progressive difficulty...
429 1. COMPILE TIME LTLIBRARIES
430 ***************************
432 Alexandre Oliva wrote:
433 >
434 > [[1.1]] the programmer knows that his library is completely
435 > self-contained, it does not depend on any external symbols
436 > (-no-undefined)
438 1.2) The link mode command line to libtool contains no -l options,
439 which implies your fallback method (try to link a shared library
440 as if `-no-undefined' had been specified, or if that fails build
441 only a static library).
443 1.3) The programmer knows that resolving all of the symbols in his
444 library requires linking deplibs, and is able to specify all of
445 them on the link line (some if these may be installed .la files
446 which have deplibs of their own which libtool must also link
447 with).
449 > [[1.4]] the programmer knows that there may be symbols in his library
450 > that are going to be supplied by another library, which [[is]]
451 > unknown in advance. If such dependencies exist, they have to
452 > be resolved at program-linking time (-allow-undefined == default)
454 In the future maybe libtool will be able to do a two stage link
455 for platforms which can't do `-allow-undefined', the first link
456 to find which symbols are unresolved, the second against a
457 temporarily generated set of stubs... I'm not sure whether the
458 stage 2 lib can then resolve its stubbed functions against a
459 different library when it is subsequently linked into an
460 executable? Perhaps I am reiterating Ian's idea about stubbing
461 on broken platforms?
463 In the present, broken platforms will have to manage with static
464 libraries in this case.
466 2. RUNTIME LTLIBRARIES
467 **********************
469 > [[2.1]] the programmer needs a library foo that is completely
470 > self-contained, so that he can be sure that dlopen(foo) works,
471 > and just adding -lfoo *after* the library is installed will be
472 > fine (-self-contained ?)
474 2.2) The programmer needs a library that can be dlopened, but which
475 can have all of its symbols resolved at link time with deplibs.
476 A small amount of magic in the form a .c and .h distributed with
477 libtool (as suggested by Gord) is enough to make sure deplibs
478 are dlopened if necessary and then the library itself is loaded.
479 At best, this will only be supported on platforms for which
480 libtool can generate shared libraries, perhaps only a (large)
481 subset of those.
483 2.3) The programmer needs a library that can be dlopened, and
484 doesn't know at link time how all of the symbols will be resolved.
485 A (small) subset of the platforms for which libtool can generate
486 shared libraries, will be handled by the aforementioned magic.
487 For the unhandled cases dld will be required.
489 > [[2.4]] although a library is not going to be self-contained,
490 > [[snip]] the platform does not support libraries with undefined
491 > symbols, a shared library is badly needed, [[This will]] require
492 > dld.
494 NOTE: in the above, I am assuming that
495 all-supported-platforms >= (large) >= (small) > no-platforms
497 I don't see any need to add anymore command line switches, except
498 perhaps to tell libtool whether this is a compile time or runtime
499 library, but even that may prove unnecessary.
501 The line between 1.3 and 1.4 could probably use some clarification; what
502 if the link line includes several deplibs, but some symbols are
503 still unresolved? 1.4? Maybe... what if the platform doesn't support
504 `-no-undefined'? Perhaps there is a 1.3.5? In any case, for maximum
505 portability, we want to keep the number of cases of 1.4 to a minimum.
507 Cheers,
508 Gary.
510 From wmperry@aventail.com Sun Nov 1 01:03 EDT 1998
511 Received: from grande.dcc.unicamp.br (grande.dcc.unicamp.br [143.106.7.8])
512 by amazonas.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA29973
513 for <oliva@amazonas.dcc.unicamp.br>; Sun, 1 Nov 1998 01:03:04 -0200 (EDT)
514 Received: from slow.bp.aventail.com (vina05.cntwk.net [207.205.120.131])
515 by grande.dcc.unicamp.br (8.8.5/8.8.5) with ESMTP id BAA10397
516 for <oliva@dcc.unicamp.br>; Sun, 1 Nov 1998 01:02:59 -0200 (EDT)
517 Received: from kramer-fast.bp.aventail.com (kramer-fast.bp.aventail.com [192.168.200.2])
518 by slow.bp.aventail.com (8.8.5/8.8.5) with ESMTP id SAA31093;
519 Sat, 31 Oct 1998 18:03:52 -0800
520 Received: (from wmperry@localhost)
521 by kramer-fast.bp.aventail.com (8.8.5/8.8.5) id WAA21542;
522 Sat, 31 Oct 1998 22:04:49 -0500
523 Sender: wmperry@aventail.com
524 To: Gordon Matzigkeit <gord@trick.fig.org>
525 Cc: Alexandre Oliva <oliva@dcc.unicamp.br>
526 Subject: Re: libtool 1.2 problems...
527 References: <199810251708.MAA02237@kramer-fast.bp.aventail.com> <oryapxaste.fsf@araguaia.dcc.unicamp.br> <86zpac2z99.fsf@trick.fig.org>
528 Errors-to: wmperry@aventail.com
529 Reply-to: wmperry@aventail.com
530 X-Face: O~Rn;(l][/-o1sALg4A@xpE:9-"'IR[%;,,!m7</SYF`{vYQ(&RI1&EiH[FvT;J}@f!4kfz
531 x_!Y#=y{Uuj9GvUi=cPuajQ(Z42R[wE@{G,sn$qGr5g/wnb*"*ktI+,CD}1Z'wxrM2ag-r0p5I6\nA
532 [WJopW_J.WY;
533 Mime-Version: 1.0 (generated by tm-edit 7.108)
534 From: wmperry@aventail.com (William M. Perry)
535 Date: 31 Oct 1998 22:04:49 -0500
536 In-Reply-To: Gordon Matzigkeit's message of "31 Oct 1998 15:32:50 -0600"
537 Message-ID: <867lxgazam.fsf@kramer-fast.bp.aventail.com>
538 X-Mailer: Gnus v5.6.8/XEmacs 21.0 - "Pyrenean-pre6"
539 Content-Type: text/plain; charset=US-ASCII
540 X-Content-Length: 2306
541 Xref: araguaia.dcc.unicamp.br libtool-deplibs:9
542 Lines: 66
543 X-Gnus-Article-Number: 9 Fri Nov 20 23:23:12 1998
545 Gordon Matzigkeit <gord@trick.fig.org> writes:
547 > >>>>> Alexandre Oliva writes:
548 >
549 > AO> I can understand why we'd want all that stuff on systems with
550 > AO> brain-damaged dynamic linkers or such, but on Linux? Gord?
551 >
552 > No specific reason. I was trying to implement something that would
553 > work on all platforms, including Linux.
554 >
555 > >> I think optionally having a PUBLIC_API preprocessor macro or
556 > >> something might be handy.
557 >
558 > AO> Thomas Tanner has recently submitted a patch that implements
559 > AO> that, I think. I still couldn't find the time to look carefully
560 > AO> at the patch, but, from the text description, it looks like
561 > AO> that's exactly what it does.
562 >
563 > I think it's a good idea to be able to specify global symbols
564 > explicitly. That's part of the glibc versioning system that I was
565 > alluding to earlier.
566 >
567 > If you look at the `--version-script' option to GNU ld
568 > ((ld.info)Version Script.), then you'll see more details.
570 To restrict globally visible symbols, here's the info I've got. :) i've
571 been using this for quite a while in our server product. All hail the
572 NSA.
574 Linux: '--retain-symbols-file <FILENAME>' , with all the symbols you want
575 exported in <FILENAME>
577 OSF1: '-hidden -exported_symbol "symname-or-wildcardspec"'
579 AIX: you just restrict what you but in the export list you pass to
580 -bE:<FILENAME>.
582 HP/UX: '+e symname' on the link line for each exported symbol you want
584 Solaris: create a map file for the linker that looks like:
585 {
586 global:
587 symname1;
588 symname2;
589 symname3;
590 local:
591 *;
592 }
594 And use -M <MAPFILE> on the link line.
596 BSD/OS 3.x is the only system I couldn't find a way to support this symbol
597 hiding on. But you might be able to do it better with BSD/OS 4.x now that
598 they have finally moved to elf.
600 BTW: What are the subscription directions for libtool-bugs or a general
601 discussion list for stuff like this? I've had lots of experience over the
602 last 3 years with dynamic loading on various platforms, and would love to
603 get libtool to the point where I could use it for all of our products here
604 at aventail. Less stuff for me to officially maintain. :)
606 I'd also like to see DLD 4.x eventually so that I can just support it and
607 ditch all the crufty junk we are using right now. :) Abstraction good.
609 -Bill P.