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
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: 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
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 http://people.redhat.com/petersen/ Perhaps it is best if you could test that, please, and report any problems, thanks.
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.
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? Thank you.
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. Thanks
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.
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.
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 when relinking?
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.
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: 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.
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 upstream.
There is a libtool ChangeLog entry that seems vaguely related: 2002-11-03 Ossama Othman <ossama.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.