[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/

[sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

[Dave Allured]

Follow-up Comment #13, sr #111069 (group libtool):

[comment #7 comment #7:]
> ... Newer versions of ld64 already know to disable chained fixups when it is
passed `-undefined dynamic_lookup`. This patch is really only relevant for a
small range of versions of ld64 that doesn't have this behaviour.

Ideally '-no_fixup_chains' should be limited to this small range of linker
versions where the extra flag is actually needed to prevent error, or to
suppress an unwanted warning message.  Can anyone say which versions these
actually are, let alone how to code the proper test for them?


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[sr #111069] libtool: patch: Fix dynamic_lookup warnings from new Mac linker

[Ryan Carsten Schmidt]

Follow-up Comment #12, sr #111069 (group libtool):

This is the commit:

https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development=001d22d7d587e85a911c71c4d0c798ede8014b77

It's a good idea to always provide a link to the commit.

You could remove the comment that "$MACOSX_DEPLOYMENT_TARGET seems to be
deprecated as a darwin environment variable" because I don't know what you're
talking about there and it has nothing to do with this issue.

In the check for macOS version -- "11.[[3-7]]*|1[[2-4]]*)" -- you should
change it to "11.[[3-7]]*|1[[2-4]].*)". You want to check whether the version
begins with "12." or "13." or "14.", not whether it begins with "12", "13", or
"14". Fixing this will avoid problems with hypothetical future macOS version
120 and above.

Similarly, in the check for Xcode CLT version -- "*version:\ 1[[3-5]]*)" --
you should change it to "*version:\ 1[[3-5]].*)" so that you check whether it
begins with "13.", "14.", or "15.", rather than whether it begins with "13",
"14", or "15".

Sloppy libtool version numbering checks, particularly in this area of the
code, have been the cause of two major fiascos in the macOS world before (the
one where libtool did not anticipate the existence of OS X 10.10 and the one
where it did not anticipate the existence of macOS 11). It would behoove the
libtool project to create a proper version number comparison function and use
it everywhere, rather than faking it with string comparisons, to avoid such
problems in the future.

Once you've identified an Xcode CLT version that needs the fix, I'm not sure
why you're repeating most of the definition of the variable with
"_lt_dar_allow_undefined='$wl-undefined ${wl}dynamic_lookup
$wl-no_fixup_chains'". Can't you just append the one flag to the existing
variable's value?

Finally, you're only checking the version of the Xcode CLT. The user does not
necessarily have the Xcode CLT installed. They might instead have only the
full Xcode installed. In that case, your code will not add the required flag.
Instead of trying to identify whether the user has the full Xcode or the Xcode
CLT (or, if both, which one is selected for use), you may want to just try to
figure out which linker they have. Unfortunately, I couldn't find an option to
ld to display its version number.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/