[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
Red Hat GCC Developer                  address@hidden,}
CS PhD student at IC-Unicamp        address@hidden,}
Free Software Evangelist    *Please* write to mailing lists, not to me

reply via email to

[Prev in Thread] Current Thread [Next in Thread]