[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: library relocation
RE: library relocation
Wed, 23 Oct 2002 09:51:58 -0700
Looks interesting. I have a solution for AIX and HP-UX as well but those
diffs are slightly more involved. First, instead of directly linking all .lo
files into the .so library, I use ld -r to combine all .lo files into a
single object file. (Do this for all platforms, unconditionally.) This single
object file is used to create both the intermediate/working and
final/installed shared library. This approach saves a lot of time when it
comes to the relinking step, especially with AIX's linker.
The next step is ugly: we use the appropriate options to embed the desired
library search path, and then to avoid any undesired -L paths from being
embedded, I symlink any missing -L dependent libraries into the target
directory, cd to the target directory and link from there, using "-L." in the
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Paul E Johnson
> Sent: Wednesday, October 23, 2002 9:22 AM
> To: Frederic Gobry; address@hidden
> Subject: Re: library relocation
> 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
> 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:
> 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
> Libtool mailing list