Hi all,
Resurrecting an old bug dating back to 2008, still present in current
libtool 2.4.6-14.
We've recently encountered that bug with the inn2 package. The
--preserve-dup-deps does not do what it is supposed to do because of a
broken optimization (marked as FIXME in the libtool code).
Suggestion of patch:
--- ltmain.sh.orig 2020-11-21 08:16:10.480694237 +0100
+++ ltmain.sh 2020-11-21 08:43:00.848365987 +0100
@@ -8686,41 +8686,45 @@
eval tmp_libs=\"\$$var\"
new_libs=
for deplib in $tmp_libs; do
- # FIXME: Pedantically, this is the right thing to do, so
- # that some nasty dependency loop isn't accidentally
- # broken:
- #new_libs="$deplib $new_libs"
- # Pragmatically, this seems to cause very few problems in
- # practice:
- case $deplib in
- -L*) new_libs="$deplib $new_libs" ;;
- -R*) ;;
- *)
- # And here is the reason: when a library appears more
- # than once as an explicit dependence of a library, or
- # is implicitly linked in more than once by the
- # compiler, it is considered special, and multiple
- # occurrences thereof are not removed. Compare this
- # with having the same library being listed as a
- # dependency of multiple other libraries: in this case,
- # we know (pedantically, we assume) the library does not
- # need to be listed more than once, so we keep only the
- # last copy. This is not always right, but it is rare
- # enough that we require users that really mean to play
- # such unportable linking tricks to link the library
- # using -Wl,-lname, so that libtool does not consider it
- # for duplicate removal.
- case " $specialdeplibs " in
- *" $deplib "*) new_libs="$deplib $new_libs" ;;
+ if $opt_preserve_dup_deps; then
+ # Pedantically, this is the right thing to do, so
+ # that some nasty dependency loop isn't accidentally
+ # broken.
+ new_libs="$deplib $new_libs"
+ else
+ # Pragmatically, this seems to cause very few problems in
+ # practice:
+ case $deplib in
+ -L*) new_libs="$deplib $new_libs" ;;
+ -R*) ;;
*)
- case " $new_libs " in
- *" $deplib "*) ;;
- *) new_libs="$deplib $new_libs" ;;
- esac
- ;;
- esac
- ;;
- esac
+ # And here is the reason: when a library appears more
+ # than once as an explicit dependence of a library, or
+ # is implicitly linked in more than once by the
+ # compiler, it is considered special, and multiple
+ # occurrences thereof are not removed. Compare this
+ # with having the same library being listed as a
+ # dependency of multiple other libraries: in this case,
+ # we know (pedantically, we assume) the library does not
+ # need to be listed more than once, so we keep only the
+ # last copy. This is not always right, but it is rare
+ # enough that we require users that really mean to play
+ # such unportable linking tricks to link the library
+ # using -Wl,-lname, so that libtool does not consider it
+ # for duplicate removal. And if not possible for portability
+ # reasons, then --preserve-dup-deps should be used.
+ case " $specialdeplibs " in
+ *" $deplib "*) new_libs="$deplib $new_libs" ;;
+ *)
+ case " $new_libs " in
+ *" $deplib "*) ;;
+ *) new_libs="$deplib $new_libs" ;;
+ esac
+ ;;
+ esac
+ ;;
+ esac
+ fi
done
tmp_libs=
for deplib in $new_libs; do
Works OK witn inn2.
--
Julien ÉLIE
« – Le bureau des renseignements ?
– Sais pas. Adressez-vous aux renseignements, ils vous
renseigneront. » (Astérix)
