[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
From: |
Ileana Dumitrescu |
Date: |
Fri, 19 Jul 2024 12:43:44 -0400 (EDT) |
branch: master
commit 7f86baed1aff6fc568fd44d4b1ca3076c2bdfaf5
Author: Julien ÉLIE <julien@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 | 70 ++++++++++++++++++++++++++++-------------------------
1 file changed, 37 insertions(+), 33 deletions(-)
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 991228ae..5221b87f 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
@@ -6730,42 +6730,46 @@ 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" ;;
+ 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
- master updated (cc511550 -> 383c97a8), Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject],
Ileana Dumitrescu <=
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19
- [no subject], Ileana Dumitrescu, 2024/07/19