Bug 71989 - relink fails when cross compiling
relink fails when cross compiling
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: libtool (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-20 12:13 EDT by Tomas Winkler
Modified: 2007-04-18 12:45 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-20 01:46:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 12:14 EDT, Tomas Winkler
no flags Details | Diff
slightly improved version of patch on ltmain.in (1.41 KB, patch)
2002-08-21 03:19 EDT, Jens Petersen
no flags Details | Diff
merge of this destdir patch onto relink patch basically (1.45 KB, patch)
2002-08-22 05:57 EDT, 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 12:27 EDT, Tomas Winkler
no flags Details
relink with patch from libtool mailing list (36.41 KB, text/plain)
2002-08-28 12:28 EDT, Tomas Winkler
no flags Details
make DESTDIR/libdir precede libdir (440 bytes, patch)
2002-08-29 13:42 EDT, Jens Petersen
no flags Details | Diff

  None (edit)
Description Tomas Winkler 2002-08-20 12:13:34 EDT
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:
Always

Steps to Reproduce:
1 env CC=<path_to_cross_compiler> ./configure --prefix=/usr 
2.make 
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 @@
 	      add="-l$name"
 	    else
 	      # 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
 	      add="-l$name"
 	    fi
 
@@ -4106,12 +4110,21 @@
 	esac
 
 	# Add the libdir to current_libdirs if it is the destination.
+	DESTDIR=
 	if test "X$destdir" = "X$libdir"; then
 	  case "$current_libdirs " in
 	  *" $libdir "*) ;;
 	  *) current_libdirs="$current_libdirs $libdir" ;;
 	  esac
 	else
+	  case "$destdir" in
+	    *"$libdir")
+	      DESTDIR=`$echo "$destdir" | sed -e 's!'"$libdir"'$!!'`
+	      if test "X$destdir" != "X$DESTDIR$libdir"; then
+		DESTDIR=
+	      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 :
 	  else
@@ -4132,6 +4146,7 @@
 	    continue
 	  fi
 	fi
+	unset DESTDIR
 
 	# See the names of the shared library.
 	set dummy $library_names
Comment 1 Tomas Winkler 2002-08-20 12:14:35 EDT
Created attachment 71645 [details]
reling patch to ltmain.sh
Comment 2 Jens Petersen 2002-08-21 01:39:53 EDT
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 02:26:44 EDT
OK, it guess it is this:

http://mail.gnu.org/pipermail/bug-libtool/2002-February/003019.html

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

http://mail.gnu.org/pipermail/libtool/2002-April/006268.html
Comment 4 Jens Petersen 2002-08-21 02:54:36 EDT
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 03:19:45 EDT
Created attachment 71844 [details]
slightly improved version of patch on ltmain.in
Comment 6 Alexandre Oliva 2002-08-21 03:24:20 EDT
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 05:56:36 EDT
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 05:55:10 EDT
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 05:57:08 EDT
Created attachment 72213 [details]
merge of this destdir patch onto relink patch basically
Comment 10 Jens Petersen 2002-08-22 06:58:19 EDT
I put a srpm and i386 test package, libtool-1.4.2-12.1, under
http://people.redhat.com/petersen/

Perhaps it is best if you could test that, please, and report any
problems, thanks.
Comment 11 Tomas Winkler 2002-08-22 08:19:25 EDT
I took  the rpm 1.4.12.1  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 10:45:41 EDT
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 12:57:46 EDT
I took  the rpm 1.4.12.1  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 03:09:22 EDT
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 05:04:12 EDT
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 12:27:31 EDT
Created attachment 73545 [details]
result of relinking when using  libtool-1.4.2-12.1
Comment 17 Tomas Winkler 2002-08-28 12:28:57 EDT
Created attachment 73546 [details]
relink with patch from libtool mailing list
Comment 18 Tomas Winkler 2002-08-28 12:42:40 EDT
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 13:41:21 EDT
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 13:42:45 EDT
Created attachment 73765 [details]
make DESTDIR/libdir precede libdir
Comment 21 Tomas Winkler 2002-09-01 05:01:32 EDT
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.
Thanks
Comment 22 Jens Petersen 2002-09-02 07:15:58 EDT
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 13:48:55 EDT
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 18:27:49 EST
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 16:52:01 EDT
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 18:32:25 EDT
It seems that it hasn't still been fixed on libtool-1.5-3 either...
Comment 29 Jens Petersen 2003-07-07 23:14:34 EDT
Alexander, do you agree that it is ok to remove "-L$libdir" completely
when relinking?
Comment 30 Alexandre Oliva 2003-07-08 00:03:28 EDT
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
DESTDIR.
Comment 31 Fernando Nasser 2003-07-08 09:50:08 EDT
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 11:52:02 EDT
Hmm, I still see the problem with:

libtool-1.5-3
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 01:28:02 EDT
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 07:38:30 EDT
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
upstream.
Comment 35 Daniel Reed 2004-08-20 01:46:54 EDT
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.