[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Three problems with libtools
From: |
Alexandre Oliva |
Subject: |
Re: Three problems with libtools |
Date: |
03 Oct 2000 04:33:55 -0200 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands) |
On Oct 2, 2000, Marc Espie <address@hidden> 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 address@hidden, redhat.com}
CS PhD student at IC-Unicamp address@hidden, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me