GNU Libtool - Patches: patch #9999, Fix --preserve-dup-deps flag not...
You are not allowed to post comments on this tracker with your current authentication level.
patch #9999: Fix --preserve-dup-deps flag not to strip some duplicates
Submitter: | Julien ÉLIE <iulius> | ||
Submitted: | Sun 22 Nov 2020 11:03:40 AM UTC | ||
Category: | None | Priority: | 5 - Normal |
Status: | None | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
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