From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Description of problem:
relink fails when installing a cross compiled software with prefix=/usr and DESTDIR=/something. Since -
L/usr/lib and -rpath /usr/lib are used the software
are relinked to host libraries instead to target
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1 env CC=<path_to_cross_compiler> ./configure --prefix=/usr
2.make install DESTDIR=/tmp
Actual Results: relinkage fails with conflicts in symbols
Expected Results: smooth installation
There is a patch in libtool-1.4.2-8.().rpm and above from rawhide which solves the DESTDIR isntallation
but it sitll not good enough for cross compiliaton. I found another patch in libtool mailing list that
solves the problem also for cross compilation
--- /usr/share/libtool/ltmain.sh.orig Thu Jul 5 16:41:01 2001
+++ /usr/share/libtool/ltmain.sh Sat Mar 2 18:45:59 2002
@@ -1861,7 +1861,11 @@
# We cannot seem to hardcode it, guess we'll fake it.
+ if test "X$installed" = Xyes; then
@@ -4106,12 +4110,21 @@
# Add the libdir to current_libdirs if it is the destination.
if test "X$destdir" = "X$libdir"; then
case "$current_libdirs " in
*" $libdir "*) ;;
*) current_libdirs="$current_libdirs $libdir" ;;
+ case "$destdir" in
+ DESTDIR=`$echo "$destdir" | sed -e 's!'"$libdir"'$!!'`
+ if test "X$destdir" != "X$DESTDIR$libdir"; then
# Note the libdir as a future libdir.
case "$future_libdirs " in
*" $libdir "*) ;;
@@ -4125,6 +4138,7 @@
if test -n "$relink_command"; then
$echo "$modename: warning: relinking \`$file'" 1>&2
+ export DESTDIR
if $run eval "$relink_command"; then :
@@ -4132,6 +4146,7 @@
+ unset DESTDIR
# See the names of the shared library.
set dummy $library_names
Created attachment 71645 [details]
reling patch to ltmain.sh
Thanks for the report.
The patch is by Bruno Haible, right? BTW, due you have a link to the original
article I am having trouble finding it.
OK, it guess it is this:
if I'm not mistaken. The above patch appearing in:
Just discussed this a little with Alex Oliva and he suggested a couple of
improvement to the patch:
* quoting the sed expression properly like in other parts of libtool
* using "unset" more carefully, since some shells don't support it.
Created attachment 71844 [details]
slightly improved version of patch on ltmain.in
Looks good to me. Time to test it with one of the packages that used to fail
before the old relink patch.
Hmmm, AFAICT, the results were not as good as I had hoped.
I tested this patch by trying to rebuild pango-0.23.90-2 on a RHL 7.3 box
with ltmain.sh using this patch.
Unfortunately the build fails in the same way as when the fixed-ltmain.sh
file is not used (ie the equivalent of the current relink patch).
That's a shame.
Actually I get the impression now that Haible's patch is kind of orthogonal
to our relink patch. To be honest I don't fully understand either of the
patches, but AFAICT Haible's patch is basically concerned with improving
libtool's DESTDIR handling, whereas the relink patch in our libtool is
fixing a problem with you guessed it relinking...
So now I made a patch to merge in the above destdir package, and tested it
and both "make check" and the aforementioned pango rebuild test work fine.
I will attach the patch below. Could you please test it and in particular
with cross-building to make sure it fixes the reported problem.
Created attachment 72213 [details]
merge of this destdir patch onto relink patch basically
I put a srpm and i386 test package, libtool-1.4.2-12.1, under
Perhaps it is best if you could test that, please, and report any
I took the rpm 188.8.131.52 and it STILL not good for cross compiliation becuase -L/usr/lib. If I (a user)
do not provide explicitely -L flags then the linkage stage SHOULD NOT contain such flags regardles of
the issue that the prefix=/usr, compiler nows the default library path.
Thanks for testing it. Ok, perhaps my merge was not good enough:
I'll another look at it later.
Is it possible you could attach some cross-compile output, both broken
and working just to get a better idea of what should be happening.
Against what version should I apply libtool-1.4.2-destdir-71989.patch. When I've
tried patch the vanila 1.4.2 it produced
Hunk #1 FAILED at 1940.
Hunk #2 succeeded at 4145 (offset -58 lines).
Hunk #3 succeeded at 4235 with fuzz 2 (offset -18 lines).
Hunk #4 succeeded at 4203 with fuzz 1 (offset -58 lines).
1 out of 4 hunks FAILED -- saving rejects to file ltmain.sh.rej
It should apply against one of our recent libtool srpms.
A slightly improved version of the patch is in the above mentioned srpm.
Created attachment 73545 [details]
result of relinking when using libtool-1.4.2-12.1
Created attachment 73546 [details]
relink with patch from libtool mailing list
Upon the request I've posted two outputs of relinking with libtool when cross
compiling. One with 71989 patches and the second is patch from libtool mailing
list I posted earlier. The only difference is that there is no -L/usr/lib in the
later one .. and that is the correct behavior. -L/usr/lib is not explicitly
stated in LDFLAGS or any other linkage flag and is pushed here by the libtool
probably because --prefix=/usr/lib. As I've stated before no other paths then
those stated explicitly in LDFLAGS should be present in the linkage arguments.
Thank you, that made the problem much clearer: I think the problem
was the ordering of the library paths.
With the patch below to the destdir patch, both "make check" and the pango
test seem to be fine. Could you please try it with cross-compiling also?
Created attachment 73765 [details]
make DESTDIR/libdir precede libdir
The patch is NOT GOOD. I really don't know how to convey this message :(.
The system path e.g. -L/usr/lib should not be assigned to add_dir it will never
ever work in cross compilation. The order of DESTDIR/libdir and libdir in
compilation command line doesn't matter since the compiler first look on the
command line arguments and only then it looks at its default path. So If I'm
linking against for examle libcrypto.so. because of flag -L/usr/lib it first
finds NATIVE /usr/lib/libcrypto.so and not
/<cross_compiler_path>/lib/libcrypto.so. and as the result the linkage will
fail. Please let me know If I'm understood.
Ok, I am not really familiar with cross-compiling, but now I understand
what you're say about the cross-compiler default lib paths.
The problem I have is that the original patch seems to break relinking
during native package building. We need a solution that works for
both these cases.
Are you saying the above patch should be
-+ add_dir="$add_dir -L$DESTDIR$libdir"
? I suspect that will break native relinking, but I'll try to
check it later explicitly.
I think that -L$libdir should not be added to add_dir as well as
-L$DESTDIR/$libdir should not be added if DESTDIR is empty. I've traced the
script and found out that DESDIR is always empty when relinking but
set to $DESTDIR/$prefix/lib. I don't really underestand why is that relinking
needed at all.
This bug rises its ugly head also when e.g. building an RPM package of the
current GIMP betas (1.3.x): relinking with '-L/usr/lib' causes libgimpmodule to
be linked against libgimpbase of the (installed) older version, i.e.
libgimpmodule-1.3.so.13 against libgimpbase-1.3.so.12. See
http://bugzilla.gnome.org/show_bug.cgi?id=106434 for further info.
I fully concur with tomasw's last comment, i.e. '-L$libdir' should not happen at
all (unless specified by the user).
Could we please fix this? I have looked for how to work around this and I only
found that I could manually relink it for proper behaviour, which is just insane
when building RPMs ;-).
It also breaks unixODBC package building.
I bet there are several othe packages affected by this but the maintainers
haven't noticed that they are linking against the libraries they have in their
/usr/lib and not the ones they just built.
And it is not fixed in the libtool 1.4.3 that came with 9.
It seems that it hasn't still been fixed on libtool-1.5-3 either...
Alexander, do you agree that it is ok to remove "-L$libdir" completely
Nope. The very point of relinking is that have to link with the dependencies
that have already been installed. If they haven't been installed, well...
something is broken. If they have, we want to search $DESTDIR$libdir first, in
case the new libraries were part of this package we're installing, or $libdir,
in case they were in there before. I agree that adding only $DESTDIR$libdir
might feels like the right thing to do, but it is not. I still don't see a
correct scenario in which adding $DESTDIR$libdir and $libdir could possibly
break something. I could use a small testcase, e.g., a tarball or two that I
could configure with some prefix, build, install, then configure with the smae
prefix, and a different --enable flag that would cause some incompatible change
to be introduced in some library that is part of the package, and install with
Sorry, I posted a note to bug #91110 but forgot about this one.
The reordering of the -L did solve my problem. As there is a -L for the DESTDIR
libraries before the one for /usr/lib things get linked correctly.
So, this is fixed in 1.5 libtool.
Hmm, I still see the problem with:
gimp-1.3.16 built on a system with gimp-1.3.12 installed
though that is likely to be an aftereffect of another bug (don't know if it is
libtool) which generates library files without '.so' in them.
Is this still an issue, or can I close it? I do not see any related
patches in current libtool.
It certainly still is an issue for RHL9 :-)
IIRC the destdir patch made it to libtool CVS, so if the latest
libtool doesn't use our patch, it's because the patch is already in
There is a libtool ChangeLog entry that seems vaguely related:
2002-11-03 Ossama Othman <email@example.com>
* ltmain.in: add support for installing into temporary
staging area (e.g. 'make install DESTDIR=...')
(The only patch we currently apply to libtool is .multilib.)
Please re-open if this needs to be investigated further. Thanks.