Dear list,
us hackable:1 developers [1] have been cross-compiling libtool-based
projects for a while. We are using a staging directory where libraries
and programs are installed as they are compiled.
Unfortunately, libtool was consistently failing at using the right
absolute path to the libraries there, picking up native libraries of the
same name instead. We've come up with this patch to solve the situation
in our case, together with the -inst-prefix-dir flag. I don't think it
has any side-effects either.
[1] http://www.hackable1.org/
Cheers,
--
Pierre Pronchery, security consultant, DUEKIN Consulting
email: pierre.pronch...@duekin.com Gubener Straße 40
PGP: 36F0 CA45 CA07 C871 8E31 10243 Berlin, Germany
6FC4 6BBE DBA9 02A0 E77E Web: http://www.duekin.com/
Phone: +49 177 472 7481 Phone: +49 30 420 81 859
Fax: +49 30 420 81 861
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index ebd3909..927f1df 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5333,9 +5333,11 @@ func_mode_link ()
fi
if test "$linkmode" = prog; then
test -n "$add_dir" && compile_deplibs="$add_dir $compile_deplibs"
+ test -f "$inst_prefix_dir$add" && add="$inst_prefix_dir$add"
test -n "$add" && compile_deplibs="$add $compile_deplibs"
else
test -n "$add_dir" && deplibs="$add_dir $deplibs"
+ test -f "$inst_prefix_dir$add" && add="$inst_prefix_dir$add"
test -n "$add" && deplibs="$add $deplibs"
if test "$hardcode_direct" != yes &&
test "$hardcode_minus_L" != yes &&
