URL:
<https://savannah.gnu.org/patch/?9999>
Summary: Fix --preserve-dup-deps flag not to strip some
duplicates
Project: GNU Libtool
Submitted by: iulius
Submitted on: Sun 22 Nov 2020 11:03:40 AM UTC
Category: None
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Originator Email:
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
Hi all,
We've recently encountered a build issue because of circular dependencies that
were not solved, even with the use of --preserve-dup-deps in Libtool. It
appears that --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 with that patch.
Thanks for your work on Libtool,
--
Julien ÉLIE
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/patch/?9999>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
