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

Re: help: disabling relinking stupidity in libtool



On Tue, 2003-06-10 at 21:31, Ari Pollak wrote:

> Scott James Remnant wrote:
> > Is libtool picking up the OLD (/usr/lib) version of the library, rather
> > than the version in DESTDIR, and relinking the application with it (and
> > that old version's dependant library)?
> 
> Correct. If the original library was not installed, it wouldn't be a 
> problem. But alas, I'm not going to make the library Build-Conflict itself.
> As of the latest version of the debian/rules for gimp1.3, I'm using 
> DESTDIR instead of prefix, which (from what I've seen on the list) 
> should theoretically make things better, but it doesn't really make any 
> difference except for certain brain-dead upstream Makefile issues. 
> 
Ok, so let's go back to your ldd output (so I understand exactly what's
up):

> $ ldd debian/libgimp1.3/usr/lib/libgimpui-1.3.so.15
>          libgimp-1.3.so.14 => /usr/lib/libgimp-1.3.so.14 (0x40022000)
>          libgimpwidgets-1.3.so.14 => /usr/lib/libgimpwidgets-1.3.so.14
> (0x40039000)
>          libgimpbase-1.3.so.15 => not found
> 
I'm guessing here that it is *NOT* supposed to link with both of the
.so.14 libraries, it's supposed to link to .so.15 equivalents of BOTH?

And I'm guessing that the .so.15 being "not found" is just because you
haven't stuck LD_LIBRARY_PATH on the front?

What output are you expecting?  does (as Marcello suggested) the
following produce the right output?

LD_LIBRARY_PATH=`pwd`/debian/libgimp1.3/usr/lib ldd ...

> > It's a libtool feature[0].
> > 
> > I have a proposed-fix for this, will throw it your way as soon as I've
> > caught up with the recent libtool bugs.
> 
> Were you the one that proposed changing fakeroot to deal with libtool 
> screwage? I remember reading a thread on debian-devel about that a while 
> back, but nothing really happened with it.
> 
Nope, wasn't me.

My proposed-fix is to simply make libtool check the DESTDIR directories
first, it checks them last at the moment.

Scott
-- 
Who strongly suspects this is going to turn into another problem
like the "links to dependencies of dependencies" one.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: