branch: development
commit 938a0f4b01375fa14dde37f51be7761887dd684e
Author: Julien ÉLIE <jul...@trigofacile.com>
AuthorDate: Sat Nov 21 08:43:00 2020 +0100
ltmain.in: Fix --preserve-dup-deps stripping duplicates
Building INN with libtool otherwise failed with unresolved circular
dependencies, even with the use of --preserve-dup-deps.
---
build-aux/ltmain.in | 71 ++++++++++++++++++++++++++++-------------------------
1 file changed, 38 insertions(+), 33 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 991228ae..f850b951 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6730,42 +6730,47 @@ func_mode_link ()
# Add libraries to $var in reverse order
eval tmp_libs=\"\$$var\"
new_libs=
+ # FIXME: Pedantically, this is the right thing to do, so
+ # that some nasty dependency loop isn't accidentally
+ # broken: new_libs="$deplib $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" ;;
+ # Modification for INN in the loop (fix --preserve-dup-deps).
+ if $opt_preserve_dup_deps; then
+ 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
- ;;
+ # 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
- ;;
- esac
+ fi
done
tmp_libs=
for deplib in $new_libs; do
