Re: library relocation

[Paul E Johnson]

I think the DESTDIR patch for ltmain.sh fixes that. At least it did for 
me. I had the problem that relinking was failing with "make prefix=/blah 
install" so I retooled with DESTDIR and with this patch everything seems 
OK.  I found this through a bugs page for libtool, but I can't find that 
page now.

But I do still have the patch address:

http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html

Frederic Gobry wrote:
> Hello,
>
> I'm working on linux based embedded platforms. To build a complete
> platform, we usually compile and install our software packages in a
> directory that is specific to each developer, say:
>
>           /home/fred/frozen/usr/lib/...
>
> Then, the compiled libraries and executables that must be actually
> available on the final platform are manipulated so that they finally
> appear in
>
>        /usr/lib/...
>
> ...when the platform has booted.
>
> Here comes the problem: 
>
>   - Scenario 1: a library (let say glib) is configured with the final
>     prefix (/usr) and installed for instance with a make install
>     DESTDIR=/home/fred/....
>     
>     Then, a program that uses the library will link with sth like
>
>           -L/home/fred/frozen/lib -lglib
>  
>     Unfortunately, libtool (1.4.2a) will transform this into...
>
>             /usr/lib/libglib.so
>
>     Grr. This is not a library compiled for the same architecture.
>
>   - Scenario 2: the library is directly configured to get installed in
>     /home/fred/...
>
>     Then, the linking will be performed correctly, but a wrong rpath
>     will be added in the executable...
>
> Do you know a better method ?
> Thank,
>
> Frédéric



--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700