libstemmer @2.2.0 does not respect sdk version

[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

[jmroot (Joshua Root)]

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.

[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.)

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

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