Re: Three problems with libtools
On Tue, Oct 03, 2000 at 05:29:07AM -0200, Alexandre Oliva wrote: > I recall having had trouble on SunOS 4 when adding some PIC flag to > the command line that I used to create shared libraries. But that was > long before libtool existed, and I no longer have access to SunOS 4 > boxes to test again. > But I guess we can give it a try. As you say, it shouldn't break. > Maybe I mis-remember. Would you be so kind to post a patch to > implement this change? I can... you're aware I don't currently have a libtool assignment, nor the way to test it on quite a few platforms ? what I'm going to do is simple search for -shared, verify whether it looks like gcc/g++ -shared, and add pic_flag. > > libgcc *is* an exception, precisely because it will be pic/PIC. > I see. That's been true for GCC releases for the past 5-or-so years, > so it's probably reasonable to assume it to be the case. But it > wouldn't hurt to check that the GCC version is 2.7 or newer before > assuming libgcc is PIC. > > What we really need is some way to tell for sure whether a certain > library can be safely linked into a shared library. Something like: > > - extract the list of symbols defined in the library > - compile a position-independent object file that references all of them > - on platforms that don't allow_undefined, > . extract the list of symbols required by the library > . compile a position-independent object file that defines them all > - attempt to link a shared library with them > - cache the result? I don't know. I think that solving the problem at hand (saying that libgcc does work) would be quite enough for now. As for the more general problem, I haven't looked too closely at libtool's performance lately, but this looks like yet another instance of the generic gnu gas-plant problem... trying to be very generic and compile on everything is sometimes going to have the exact reverse effect of what you're trying to accomplish. Specifically, 4000+ lines shell-scripts are not exactly fast, which makes it hard to test on older, slower platforms. Also, the last times I did have to tweak libtool and try to find what went wrong on OpenBSD, it did take me five minutes to figure out what I wanted it to do, and two hours to find out WHERE to effect the change in that jungle of shell-scripts... I ought to give a closer look at the current development version, but having architecture cases all over the place instead of at one more or less central place in the configure section is not that good... -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Three problems with libtools
On Oct 3, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> ??? I'm advocating adding $pic_flag to the gcc that gets used to
> link. Considering that the SAME $pic_flag gets used to build the
> object files in the first place, I have trouble understanding how
> this breaks multi-libbed ABI.
Err... Indeed. :-)
I recall having had trouble on SunOS 4 when adding some PIC flag to
the command line that I used to create shared libraries. But that was
long before libtool existed, and I no longer have access to SunOS 4
boxes to test again.
But I guess we can give it a try. As you say, it shouldn't break.
Maybe I mis-remember. Would you be so kind to post a patch to
implement this change?
> libgcc *is* an exception, precisely because it will be pic/PIC.
I see. That's been true for GCC releases for the past 5-or-so years,
so it's probably reasonable to assume it to be the case. But it
wouldn't hurt to check that the GCC version is 2.7 or newer before
assuming libgcc is PIC.
What we really need is some way to tell for sure whether a certain
library can be safely linked into a shared library. Something like:
- extract the list of symbols defined in the library
- compile a position-independent object file that references all of them
- on platforms that don't allow_undefined,
. extract the list of symbols required by the library
. compile a position-independent object file that defines them all
- attempt to link a shared library with them
- cache the result?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Three problems with libtools
On Tue, Oct 03, 2000 at 04:33:55AM -0200, Alexandre Oliva wrote: > On Oct 2, 2000, Marc Espie <[EMAIL PROTECTED]> wrote: > > > * when invoking gcc to produce shared libraries, always pass pic_flag > > around. > > This can't be done on all platforms. IIRC, on SunOS4, -fPIC or -fpic > (I don't recall which one) change the ABI, so libgcc and libstdc++ > (and all other GCC libraries, for that matter) are multilibbed, and > different libraries are picked when the flag is present. Needless to > say, linking object files or libraries using different ABIs breaks at > run-time. Programs created like that usually die horribly. > > I guess the way to go is to add $pic_flag to archive_cmds on platforms > that need it. ??? I'm advocating adding $pic_flag to the gcc that gets used to link. Considering that the SAME $pic_flag gets used to build the object files in the first place, I have trouble understanding how this breaks multi-libbed ABI. If you compile object files with -fPIC on sparc, you definitely want to pick the multi-libbed version that's been compiled with -fPIC, don't you ? > > > * on OpenBSD, it is quite possible to compile shared libraries, and test > > for their presence. However, libtool does insist that libgcc ought to be > > a shared library as well... Is there a way to disable that ? > > I can always use pass_all instead, but... it would be cleaner. > > If pass_all is correct, that's the way to disable that. Using other > dependency checks means you can't link a static library into a shared > library in general. pass_all is not 100% correct. pass_all assumes that all libraries you're going to meet are suitable for linking with a shared library. Unfortunately, most .a libraries won't necessarily be, as they might not be pic code, and lead to unpure shared libraries. libgcc *is* an exception, precisely because it will be pic/PIC. Whatever. -- Marc Espie |anime, sf, juggling, unicycle, acrobatics, comics... |AmigaOS, OpenBSD, C++, perl, Icon, PostScript... | `real programmers don't die, they just get out of beta' ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Three problems with libtools
On Oct 2, 2000, Marc Espie <[EMAIL PROTECTED]> wrote:
> * when invoking gcc to produce shared libraries, always pass pic_flag
> around.
This can't be done on all platforms. IIRC, on SunOS4, -fPIC or -fpic
(I don't recall which one) change the ABI, so libgcc and libstdc++
(and all other GCC libraries, for that matter) are multilibbed, and
different libraries are picked when the flag is present. Needless to
say, linking object files or libraries using different ABIs breaks at
run-time. Programs created like that usually die horribly.
I guess the way to go is to add $pic_flag to archive_cmds on platforms
that need it.
> * on OpenBSD, it is quite possible to compile shared libraries, and test
> for their presence. However, libtool does insist that libgcc ought to be
> a shared library as well... Is there a way to disable that ?
> I can always use pass_all instead, but... it would be cleaner.
If pass_all is correct, that's the way to disable that. Using other
dependency checks means you can't link a static library into a shared
library in general.
> * the link lines output by libtool are ludicrously long.
> Notice the multiple instances of ICE and SM...
libtool must not remove multiple occurrences of -l flags, in general.
The order of -l flags is relevant, and libtool could only remove
duplicates if it could tell for sure it wouldn't make a difference.
Unfortunately, it can't tell without duplicating a lot of the effort
of the linker.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Three problems with libtools
Hi Marc, On Mon, Oct 02, 2000 at 10:41:12AM +0200, Marc Espie wrote: > * the link lines output by libtool are ludicrously long. Since our linker > does NOT prune excess libraries, but reloads the symbols each time, this > is a fairly large problem... Observe: I thought that we fixed this problem, but I also ran into this problem with one my own packages. I'll try to get this problem soon, if the rest of the team doesn't have time. -Ossama -- Ossama Othman <[EMAIL PROTECTED]> Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
