libtool
[Top][All Lists]
Advanced

[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:31:12 -0700

We have this same need when building our software. I've hacked our version of
libtool  to support this feature:

Index: ltmain.sh
===================================================================
RCS file: /var/CVSROOT/ldap/build/ltmain.sh,v
retrieving revision 1.1.1.2
retrieving revision 1.3
diff -u -r1.1.1.2 -r1.3
--- ltmain.sh   20 Sep 2002 06:21:52 -0000      1.1.1.2
+++ ltmain.sh   3 Oct 2002 17:52:00 -0000       1.3
@@ -1821,9 +1821,7 @@
            lib_linked=yes
            case $hardcode_action in
            immediate | unsupported)
-             if test "$hardcode_direct" = no; then
-               add="$dir/$linklib"
-             elif test "$hardcode_minus_L" = no; then
+             if test "$hardcode_minus_L" = no; then
                case $host in
                *-*-sunos*) add_shlibpath="$dir" ;;
                esac
@@ -3885,16 +3888,33 @@
            output="$output_objdir/$outputname"i
            # Replace all uninstalled libtool libraries with the installed
ones
            newdependency_libs=
+           newdirs=
            for deplib in $dependency_libs; do
              case $deplib in
              *.la)
-               name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`
+               name=`$echo "X$deplib" | $Xsed -e 's%^.*/lib%%' -e s%.la%%`
                eval libdir=`sed -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
                if test -z "$libdir"; then
                  $echo "$modename: \`$deplib' is not a valid libtool
archive" 1
>&2
                  exit 1
                fi
-               newdependency_libs="$newdependency_libs $libdir/$name"
+               newdependency_libs="$newdependency_libs -l$name"
+               ;;
+             -L*)
+               if test -z "$newdirs"; then
+                 newdirs=`$echo "X$deplib" | $Xsed -e s%-L%%`
+                 newdependency_libs="$newdependency_libs $deplib"
+               else
+                 for i in $newdirs /..; do
+                   libdir=`expr $deplib : ".*\($i\)"`
+                   if test "$libdir" = "$i"; then
+                       break
+                   fi
+                 done
+                 if test "$i" = /..; then
+                   newdependency_libs="$newdependency_libs $deplib"
+                 fi
+               fi
                ;;
              *) newdependency_libs="$newdependency_libs $deplib" ;;
              esac

We do some other things differently as well, but this is the most relevant
for what you're looking for. This patch prevents libtool libraries from being
replaced by their current absolute pathnames. It also tries to eliminate
redundant "-L/path" specifications.

  -- 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
> Frederic Gobry
> Sent: Wednesday, October 23, 2002 9:00 AM
> To: address@hidden
> Subject: library relocation
>
>
> 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
>
> --
> Frédéric Gobry    SMARTDATA
>       ---         http://www.smartdata.ch
> Software Engineer Lausanne - Switzerland
>                   +41 21 693 84 98
>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]