RE: library relocation

[Howard Chu]

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
>