(unknown)
Ileana Dumitrescu <[email protected]>
| Newsgroups | gmane.comp.gnu.libtool.cvs |
|---|---|
| Message-ID | <[email protected]> |
branch: development commit 938a0f4b01375fa14dde37f51be7761887dd684e Author: Julien ÉLIE <[email protected]> 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