Update of sr #111069 (group libtool):
Status: Done => In Progress
Open/Closed: Closed => Open
_______________________________________________________
Follow-up Comment #15:
[comment #12 comment #12:]
> This is the commit:
>
>
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=001d22d7d587e85a911c71c4d0c798ede8014b77
>
> It's a good idea to always provide a link to the commit.
I will start adding this into my responses.
> 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.
The comment was added to help developers understand why the
"$MACOSX_DEPLOYMENT_TARGET" environment variable was not used in processing
below it. It was mostly added to avoid confusion, but since it was not
helpful, I have removed it.
> 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.
Thank you for pointing out the missing period! I did a lot of testing locally
with different regular expressions, but I was not thinking far enough into 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?
Yes, I will edit this.
> 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.
While I would like to verify based on the linker versions that support the
'-no-fixup_chains' flag, I only know of one linker version, 711. After I do
some more testing, I hope to know some more versions to apply the flag to.
However, I _would_ like to change the current version test to a feature test
which checks whether the flag is supported by the linker. Considering all of
the issues with the version testing, the feature test seems like the better
option, but let me know what you think.
For now, I will reopen this issue until a better solution is applied.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/support/?111069>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
