[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: library relocation
From: |
Howard Chu |
Subject: |
RE: library relocation |
Date: |
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
final link.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
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
> 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
>
>
>
> _______________________________________________
> Libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/libtool
>