libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stop "relink" searching host directory when installation prefix prov


From: Martin Panter
Subject: Re: Stop "relink" searching host directory when installation prefix provided
Date: Mon, 17 Jan 2011 13:23:37 +0000

On 16 January 2011 17:13, Ralf Wildenhues <address@hidden> wrote:
> Hello Martin,
>
> * Martin Panter wrote on Sun, Jan 16, 2011 at 01:04:00PM CET:
>> Don't search host directory during "relink" if $inst_prefix is provided
>
>> --- libtool-2.4.orig/libltdl/config/ltmain.m4sh
>> +++ libtool-2.4/libltdl/config/ltmain.m4sh
>> @@ -6122,12 +6122,14 @@ func_mode_link ()
>>             fi
>>           else
>>             # We cannot seem to hardcode it, guess we'll fake it.
>> -           add_dir="-L$libdir"
>> -           # Try looking first in the location we're being installed to.
>> +
>> +           # Default if $libdir is not relative to the prefix:
>> +           add_dir="-L$libdir"
>> +
>>             if test -n "$inst_prefix_dir"; then
>>               case $libdir in
>>                 [\\/]*)
>> -                 func_append add_dir " -L$inst_prefix_dir$libdir"
>> +                 add_dir="-L$inst_prefix_dir$libdir"
>>                   ;;
>>               esac
>>             fi
>
> Wouldn't it also suffice to just prepend instead of append
> -L$inst_prefix_dir$libdir?  If no, why not?

I did some experimenting cross-compiling with Open embedded's
"gettext-0.18-r4" package using "angstrom-2008.1" distro.

With original Libtool and all relevant patches not present: (I
abbreviated the output to make it more readable)
| arm-angstrom-linux-gnueabi-libtool: relink:
arm-angstrom-linux-gnueabi-gcc . . . [*.o] . . . -L/. .
./image/usr/lib -L/usr/lib -lgettextlib -L/. .
./armv7a-angstrom-linux-gnueabi/usr/lib -lncurses -lc . . . -o
.libs/libgettextsrc-0.18.so
| /usr/lib/libncursesw.so: file not recognized: File format not recognized

With both $add_dir -L options, but swapped around as Ralf suggested:
| arm-angstrom-linux-gnueabi-libtool: relink:
arm-angstrom-linux-gnueabi-gcc . . . [*.o] . . . -L/usr/lib -L/. .
./image/usr/lib -lgettextlib -L/. .
./armv7a-angstrom-linux-gnueabi/usr/lib -lncurses -lc . . . -o
.libs/libgettextsrc-0.18.so
| /usr/lib/libgettextlib.so: file not recognized: File format not recognized

Now that I've done the experiment I vaguely remember seeing code
inside Libtool that reversed the order of all those $add_dir -L
options, just after the part identified in my patch. That would
explain what happened here, so I think the current unpatched situation
is already doing what Ralf intended.

Just for kicks, with my patch applied for only one $add_dir -L option,
a successful relink looks like:
arm-angstrom-linux-gnueabi-libtool: relink:
arm-angstrom-linux-gnueabi-gcc . . . [*.o] . . . -L/. .
./image/usr/lib -lgettextlib -L/. .
./armv7a-angstrom-linux-gnueabi/usr/lib -lncurses -lc . . . -o
.libs/libgettextsrc-0.18.so

> Asking because I'm fairly sure not everybody uses DESTDIR for cross
> compilation and assumes that the target directory is no-go land for
> us.  (I for one often do 'make install DESTDIR=/tmp/dest' merely to
> tar up the installation tree to be scp'ed to another machine where
> the NFS share is mounted rw.)

I hadn't really considered that some people would expect to implicitly
link against libraries found in the $libdir directory. I'd tend to
argue that you should have to explicitly specify a "-L$libdir" option
if you really want to link against libraries from there. (It seems
$libdir comes straight from the target ".la" file?) But I'm not an
expert on how to use Libtool and maybe common usage or other people
would disagree with me.

I also tried natively (Arch Linux) compiling gettext 0.18. Original
Libtool behaviour installing into staging directory:
libtool: relink: gcc . . . [*.o] . . . -L/. . ./stage/usr/local/lib
-L/usr/local/lib -lgettextlib -lacl -lcroco-0.6 -lglib-2.0 -lxml2
-lncurses -lc . . . -o .libs/libgettextsrc-0.18.so

I would argue that it shouldn't search the OS's /usr/local/lib for any
of the dependencies even though the target library is supposed to
eventually exist there. If any of the target's dependencies did exist
in /usr/local/lib, I'd expect I'd have to provide that directory to
the "configure" script or linker. In my gettext case, the initial link
doesn't search any usr/local/lib directory at all, and the gettextlib
dependency is already installed into the staging directory before the
above relink happens.

With my proposed patch:
libtool: relink: gcc . . . [*.o] . . . -L/. . ./stage/usr/local/lib
-lgettextlib -lacl -lcroco-0.6 -lglib-2.0 -lxml2 -lncurses -lc . . .
-o .libs/libgettextsrc-0.18.so

On 16 January 2011 17:23, Charles Wilson <address@hidden> wrote:
> Actually, Ralf's example (or one very similar to it) is the *primary*
> use of DESTDIR.  It's how many packaging tools -- like rpm, or cygport
> on cygwin -- create installable binary packages.

Agreed, that example already tends to work with unmodified Libtool. I
want to get cross-compiled installable binary packages working as
well.

-Martin



reply via email to

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