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

2024-06-22 Thread 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/




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

2024-05-30 Thread Ryan Carsten Schmidt
Follow-up Comment #6, sr #111069 (group libtool):

The libtool that was used to generate gsl 2.8's configure script includes this
patch, which is why gsl 2.8 is failing to build with older macOS toolchains
that don't understand this flag.

It does not seem like libtool should accept this patch. Chained fixups are an
intentional new feature of Apple's linker. It should not be libtool's standard
behavior to attempt to disable this new feature. It would be better to
understand whether what libtool is doing is incompatible with chained fixups,
and if so, fix that so that it works with chained fixups. I found this
third-party document describing what chained fixups are and why they are
desirable:

https://github.com/qyang-nj/llios/blob/main/dynamic_linking/chained_fixups.md


___

Reply to this item at:

  

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