[Top][All Lists]

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

Re: should libtool --relink expand lib*.la files before -L options?

From: Ralf Wildenhues
Subject: Re: should libtool --relink expand lib*.la files before -L options?
Date: Sat, 14 Jun 2008 09:14:20 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Mark,

* Mark Wright wrote on Fri, Jun 13, 2008 at 01:20:57PM CEST:
> Ralf Wildenhues <address@hidden> wrote:

> > Generally, if you want to have several versions of some library at the
> > same time, put them in distinct $prefix'es, apart from other
> > libraries. That helps to minimize such conflicts.

> One the KDE4 Solaris project we have to somehow copy with incompatible
> libraries installed in /usr by the JDS Gnome project.  Unfortunately we
> do not have that luxury.

Incompatible libs in /usr shouldn't be a problem: there's hardly any
need to place -L/usr/lib anywhere, much less near the beginning of a
link command line.  If libtool causes that, that sounds like a bug.

> But of course none of us get paid to work on KDE4 or libtool.

Well, what I was talking about wasn't a libtool limitation as such.

Imagine this situation: you have

There is no way using only -L/-l flags that you can allow the user to
mix and match a choice where one optimized library is used and one debug
variant.  It just doesn't work that way unless you resort to symlinking
or using /path/ or similar directly in a link line.  The latter
however creates nasty DT_NEEDED entries on some systems (including
Solaris, iff the library happens to not have a proper soname).

> For the libtool relink issue above and discussed earlier, on some projects
> it might help avoid other developers hitting the relink problem if libtool had
> an option to look for libraries in the build directories first.

Hrmph, it may be that I'm still misunderstanding you.  Your examples are
complex and I'm not totally sure I'm hitting the nail on the head here.

But really I see two viable installation strategies that work portably:
either one has one prefix per package, enabling one to mix and match
quite freely.  Or one has few prefixes which are somehow themed (debug
vs optimized; or old vs. new vs. newest) from which one either picks
just one directory, or there is a total ordering by which one can go.
Mixing and matching from the latter just won't work.

IOW, I still fail to see how this is a bug in libtool rather than a
problem inherent in your setups.  If this is due to my continued
misunderstanding, then please help me see why this I'm wrong.


reply via email to

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