libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[patch #9999] Fix --preserve-dup-deps flag not to strip some duplicates


From: Julien ÉLIE
Subject: [patch #9999] Fix --preserve-dup-deps flag not to strip some duplicates
Date: Sun, 22 Nov 2020 06:03:42 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]