Opened 5 months ago
Last modified 5 months ago
#69999 new defect
libstemmer @2.2.0 does not respect sdk version
Reported by: | lukaso (Lukas Oberhuber) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | libstemmer |
Description (last modified by lukaso (Lukas Oberhuber))
Even after setting this, the build still leaves libstemmer build for the MacOS version it is running on:
echo 'macosx_deployment_target 11.0' | tee -a ${PREFIX}/etc/macports/macports.conf echo 'macosx_sdk_version 11.3' | tee -a ${PREFIX}/etc/macports/macports.conf
However otool -l
is returning:
minos 11.0 sdk 13.3
The minos is correct, however the sdk version is not.
Similar issue to https://trac.macports.org/ticket/69944
Change History (5)
comment:1 Changed 5 months ago by lukaso (Lukas Oberhuber)
Description: | modified (diff) |
---|
comment:2 Changed 5 months ago by jmroot (Joshua Root)
comment:3 Changed 5 months ago by lukaso (Lukas Oberhuber)
Yes, the problem is that this will not load on a machine that doesn't have that SDK available (aka any prior version of MacOS). (I'm actually not 100% sure of this, because in all other cases I've seen, both the minos
and the sdk
have been set incorrectly and then the library will definitely not load). (See the connected issues.)
comment:4 Changed 5 months ago by jmroot (Joshua Root)
I don't think that is correct, because the way Apple would prefer apps to be developed is to use the latest SDK and set the deployment target to the oldest OS you want to be able to run on. That of course only works if you don't use any weak-linked symbols or check for them at runtime and have fallback code for when they're not available, and most OSS code doesn't have runtime checks, so you have to build against the older SDK to ensure the newer symbols are not found at configure time. But if I'm correct and the newer SDK is only being used at link time here, the choice of which symbols to use has already been made earlier, so there's no problem.
comment:5 Changed 5 months ago by lukaso (Lukas Oberhuber)
To me, it doesn't feel right to incorrectly set these settings. But being pragmatic, I'll put an exception in my check. And still hope this is fixed someday.
Does this cause any actual problems? It looks like most of the build is probably done against the selected SDK, but the SDK recorded in the lib may be changed by the post-build commands.