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

[Julien ÉLIE]

Follow-up Comment #5, patch # (group libtool):

Yes I agree with you.  On second thoughts, the "FIXME" comment should remain.


___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

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

[Julien ÉLIE]

Follow-up Comment #3, patch # (group libtool):

Many thanks!

I've had a look at the commit in the development branch.
I suggest to remove the comment "# Modification for INN in the loop (fix
--preserve-dup-deps)."

I had put it in our locally modified version of _ltmain.sh_ in INN so as to
remember the code differed here from upstream.  It is no longer necessary, now
it has been merged upstream.  I would then just remove the comment line.

Also, the "FIXME" could be removed.  The problem is fixed!


  # 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
# Modification for INN in the loop (fix --preserve-dup-deps).
if $opt_preserve_dup_deps; then
  new_libs="$deplib $new_libs"


would become:


  # 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
if $opt_preserve_dup_deps; then
  new_libs="$deplib $new_libs"


Have a nice day.


___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/

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

[Julien ÉLIE]

Follow-up Comment #1, patch # (group libtool):

FWIW, the patch was locally applied to INN in 2020, and there hasn't been any
build problem since then.  Building INN with libtool otherwise failed with
unresolved circular dependencies, even with the use of *--preserve-dup-deps*.

https://github.com/InterNetNews/inn/commit/e715e957fe7db5acc9ec1beaa9abb2ba120c287b#diff-6858ef1035c11e53d6a00ef454d86e2eab93aae2fc7f83f201069946e916c643


I believe it would be useful to fix it upstream too.  There even was a comment
in _ltmain.sh_ noting that the current code is broken and should be fixed,
along with the fix in a commented line:


# FIXME: Pedantically, this is the right thing to do, so
#that some nasty dependency loop isn't accidentally
#broken:
#new_libs="$deplib $new_libs"


The patch basically uses the right expected logic for *--preserve-dup-deps*.


___

Reply to this item at:

  

___
Message posté via Savannah
https://savannah.gnu.org/

Re: New libtool maintainer

[Julien ÉLIE]

Hi Alex,

Feel free to reach out if you have pending patches/issues you want to 
"bump", ideas for improvements, general advice for a new GNU maintainer 
- and above all if you'd like to lend a hand toward getting `libtool' up 
and running again.


Many thanks for your work on Libtool!

I believe a good start would be to integrate suggestions and patches 
from the issue tracker


  https://savannah.gnu.org/patch/?group=libtool

and maybe also some patches Debian (and other distributions) have added 
over the years to the last 2.4.6 release.  For instance:


  https://sources.debian.org/patches/libtool/2.4.6-15/


Personaly, I would of course "bump" one of the patch I provided to make 
--preserve-dup-deps work again:

  https://savannah.gnu.org/patch/?

But I wouldn't mind if that's not your top priority (I perfectly 
understand that).


And thanks again,

--
Julien ÉLIE

« J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
  (Astérix)

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

[Julien ÉLIE]

URL:
  <https://savannah.gnu.org/patch/?>

 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.
Th