libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared library depending on static library on Solaris


From: Ralf Wildenhues
Subject: Re: shared library depending on static library on Solaris
Date: Sat, 11 Jun 2005 15:33:16 +0200
User-agent: Mutt/1.5.9i

Hi Kurt,

* Kurt Roeckx wrote on Sat, Jun 11, 2005 at 02:25:42PM CEST:
> On Fri, Jun 10, 2005 at 06:31:29PM +0200, Sven Verdoolaege wrote:
> > 
> > I just tried this (this is not my development system; I just
> > used the libtool created on another system before) and
> > actually, it passes all tests (and skips one).
> > > deplibs_check_method may not be pass_all on your system.
> [...]
> > SKIP: demo-nopic.test
> 
> This test is skipped on a few arches like x86-64, hppa and s390,
> and I think the test shouldn't exists at all.

(I suppose you also mean that libtool should not put nopic code into
shared libs either; just removing the test doesn't change much.)

Fair enough.  I would actually agree with you on this issue, for the
reasons you state.  However, there is (was?) a significant user base
(and possibly distributor people, I guess) with a strong opinion against
this.  Most notably some people/packages which depend on the resulting
speed difference.

I realize Libtool needs an overhaul in this area.  My thoughts so far
were either
1) disabling nopic in shared libs at all, or
2) on exactly those systems that allow it, enabling it, and also giving
   the user the possibility to change this behavior.  (Which one to
   make the default?)

But this is all wishful thinking for Libtool version in the future.

> Most arches do not
> support having non-pic code in a shared lib, for others pic is the
> default.  Afaik, on linux, i386 is the only arch that actually
> supports non-pic code in a shared lib.

Solaris on some arches, too, I believe.

> Having non-pic code in a shared lib has as effect that the lib
> actually isn't shared by several processes, so it's a waste of
> memory.

ACK.

Regards,
Ralf




reply via email to

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