Bug 71989 - relink fails when cross compiling
Summary: relink fails when cross compiling
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtool (Show other bugs)
(Show other bugs)
Version: 9
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Reed
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-20 16:13 UTC by Tomas Winkler
Modified: 2007-04-18 16:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-20 05:46:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
reling patch to ltmain.sh (1.31 KB, patch)
2002-08-20 16:14 UTC, Tomas Winkler
no flags Details | Diff
slightly improved version of patch on ltmain.in (1.41 KB, patch)
2002-08-21 07:19 UTC, Jens Petersen
no flags Details | Diff
merge of this destdir patch onto relink patch basically (1.45 KB, patch)
2002-08-22 09:57 UTC, Jens Petersen
no flags Details | Diff
result of relinking when using libtool-1.4.2-12.1 (49.05 KB, text/plain)
2002-08-28 16:27 UTC, Tomas Winkler
no flags Details
relink with patch from libtool mailing list (36.41 KB, text/plain)
2002-08-28 16:28 UTC, Tomas Winkler
no flags Details
make DESTDIR/libdir precede libdir (440 bytes, patch)
2002-08-29 17:42 UTC, Jens Petersen
no flags Details | Diff

Description Tomas Winkler 2002-08-20 16:13:34 UTC
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):

How reproducible:

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

Additional info:

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.
-	      add_dir="-L$libdir"
+	      if test "X$installed" = Xyes; then
+		add_dir="-L$libdir"
+	      else
+		add_dir="-L$DESTDIR$libdir"
+	      fi
@@ -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
+	    *"$libdir")
+	      DESTDIR=`$echo "$destdir" | sed -e 's!'"$libdir"'$!!'`
+	      if test "X$destdir" != "X$DESTDIR$libdir"; then
+	      fi
+	      ;;
+	  esac
 	  # 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
 	  $show "$relink_command"
 	  if $run eval "$relink_command"; then :
@@ -4132,6 +4146,7 @@
+	unset DESTDIR
 	# See the names of the shared library.
 	set dummy $library_names

Comment 1 Tomas Winkler 2002-08-20 16:14:35 UTC
Created attachment 71645 [details]
reling patch to ltmain.sh

Comment 2 Jens Petersen 2002-08-21 05:39:53 UTC
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.

Comment 3 Jens Petersen 2002-08-21 06:26:44 UTC
OK, it guess it is this:


if I'm not mistaken.  The above patch appearing in:


Comment 4 Jens Petersen 2002-08-21 06:54:36 UTC
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.

Comment 5 Jens Petersen 2002-08-21 07:19:45 UTC
Created attachment 71844 [details]
slightly improved version of patch on ltmain.in

Comment 6 Alexandre Oliva 2002-08-21 07:24:20 UTC
Looks good to me.  Time to test it with one of the packages that used to fail
before the old relink patch.

Comment 7 Jens Petersen 2002-08-21 09:56:36 UTC
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.

Comment 8 Jens Petersen 2002-08-22 09:55:10 UTC
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.

Comment 9 Jens Petersen 2002-08-22 09:57:08 UTC
Created attachment 72213 [details]
merge of this destdir patch onto relink patch basically

Comment 10 Jens Petersen 2002-08-22 10:58:19 UTC
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
problems, thanks.

Comment 11 Tomas Winkler 2002-08-22 12:19:25 UTC
I took  the rpm  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.

Comment 12 Jens Petersen 2002-08-22 14:45:41 UTC
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.

Comment 13 Tomas Winkler 2002-08-22 16:57:46 UTC
I took  the rpm  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.

Comment 14 Tomas Winkler 2002-08-28 07:09:22 UTC
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

Comment 15 Jens Petersen 2002-08-28 09:04:12 UTC
It should apply against one of our recent libtool srpms.
A slightly improved version of the patch is in the above mentioned srpm.

Comment 16 Tomas Winkler 2002-08-28 16:27:31 UTC
Created attachment 73545 [details]
result of relinking when using  libtool-1.4.2-12.1

Comment 17 Tomas Winkler 2002-08-28 16:28:57 UTC
Created attachment 73546 [details]
relink with patch from libtool mailing list

Comment 18 Tomas Winkler 2002-08-28 16:42:40 UTC
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.

Comment 19 Jens Petersen 2002-08-29 17:41:21 UTC
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?
Thank you.

Comment 20 Jens Petersen 2002-08-29 17:42:45 UTC
Created attachment 73765 [details]
make DESTDIR/libdir precede libdir

Comment 21 Tomas Winkler 2002-09-01 09:01:32 UTC
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.

Comment 22 Jens Petersen 2002-09-02 11:15:58 UTC
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"
++		add_dir="-L$DESTDIR$libdir"

?  I suspect that will break native relinking, but I'll try to
check it later explicitly.

Comment 23 Tomas Winkler 2002-09-04 17:48:55 UTC
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 
$inst_prefix_dir is 
set to $DESTDIR/$prefix/lib. I don't really underestand why is that relinking
needed at all.

Comment 24 Nils Philippsen 2003-03-25 23:27:49 UTC
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 ;-).

Comment 27 Fernando Nasser 2003-06-12 20:52:01 UTC
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.

Comment 28 Fernando Nasser 2003-06-12 22:32:25 UTC
It seems that it hasn't still been fixed on libtool-1.5-3 either...

Comment 29 Jens Petersen 2003-07-08 03:14:34 UTC
Alexander, do you agree that it is ok to remove "-L$libdir" completely
when relinking?

Comment 30 Alexandre Oliva 2003-07-08 04:03:28 UTC
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

Comment 31 Fernando Nasser 2003-07-08 13:50:08 UTC
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.

Comment 32 Nils Philippsen 2003-07-08 15:52:02 UTC
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.

Comment 33 Daniel Reed 2004-08-19 05:28:02 UTC
Is this still an issue, or can I close it? I do not see any related
patches in current libtool.

Comment 34 Alexandre Oliva 2004-08-19 11:38:30 UTC
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

Comment 35 Daniel Reed 2004-08-20 05:46:54 UTC
There is a libtool ChangeLog entry that seems vaguely related:

2002-11-03  Ossama Othman  <ossama@doc.ece.uci.edu>

                   * 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.

Note You need to log in before you can comment on or make changes to this bug.