Use deployment target 10.16 on Big Sur

[ryandesign (Ryan Carsten Schmidt)]

libtool has a bug where it does not recognize MACOSX_DEPLOYMENT_TARGET being set to 11 or greater and fails to add the linker flags required to suppress undefined symbols, which many ports rely on. (#60794, #60937, #61464, #61484, #61485, #61488, but probably also hundreds of others not yet reported.)

Jeremy patched this in the libtool port months ago but I'm not sure if he reported it to the developers of libtool. Someone else recently ​reported it to libtool and I have added a reference to Jeremy's patch there but there has been no acknowledgement from the developers yet. No recent version of libtool generates code that correctly handles deployment target 11, and this incorrect code is baked into tons of projects' configure scripts, so even once a fixed version of libtool is released it might be years or never before the developers of other projects update to a fixed version of libtool and release a new version of their software.

I think we could save ourselves a lot of build failures by having MacPorts set the deployment target to 10.16 instead of 11.0 on Big Sur. As far as I understand, the compiler/linker/SDK/whatever should treat it identically, but it would let the bad libtool code work correctly.

We have enough other problems to deal with right now (implicit declaration of functions) that if we can solve this entire class of problems with a couple-line change in MacPorts base I think that would be a win.

[mf2k (Frank Schima)]

Maybe it should be a flag that can be set per port. So ports that use a correctly fixed libtool won't be broken. Something like:

use_libtool_bigsur_hack yes

Which sets the deployment target to 10.16.

[ryandesign (Ryan Carsten Schmidt)]

Setting deployment target to 10.16 on Big Sur wouldn't break anything.

[kencu (Ken)]

it only takes 10 seconds, right -- one liner in macports.conf.

but -- would that make base start looking for MacOSX10.16.sdk?

[ryandesign (Ryan Carsten Schmidt)]

Users could edit macports.conf sure, but I'm talking about modifying MacPorts base code to change the default value of the deployment target on macOS 11.

The deployment target has nothing to do with the SDK version, as far as MacPorts base code goes.

[kencu (Ken)]

It doesn't if you set it in macports.conf.

I would have to read through the base code to be sure that it wouldn't affect the default SDK selection if it was tweaked in there, but if you say you're sure it won't, then I won't bother.

One less thing to worry about.

[mcmara (Jack McMara)]

Keep in mind that adding macosx_deployment_target 10.16 to macports.conf will fix indeed some ports build, but it will break some others (for example gdk-pixbuf2). After upgrading to macOS 11, I have to comment and uncomment the above line depending by the port being built.

[ryandesign (Ryan Carsten Schmidt)]

I did not envision that this change could break any ports. Could you describe what happens with gdk-pixbuf2?

[mcmara (Jack McMara)]

I think the relevant story may be this line in the gdk-pixbuf2 build log:

:info:build distutils.errors.DistutilsPlatformError: $MACOSX_DEPLOYMENT_TARGET mismatch: now "10.16" but "11.0" during configure

I solved by commenting out the line macosx_deployment_target 10.16 while building ports that depend on it.

[ryandesign (Ryan Carsten Schmidt)]

distutils is a part of python, so my guess is that python remembers what deployment target it was configured with and distutils complains if the deployment target used to build a module now (10.16) does not match the deployment target that was used to build python earlier (11.0). It probably just does a string comparison and is not aware of the fact that deployment targets 10.16 and 11.0 mean exactly the same thing.

If that's true, then one solution would be to rebuild python with the 10.16 deployment target. In my opinion it is wrong for distutils to care about the deployment target, so another solution would be to patch python (distutils) to remove that check or at least to fix it so that it recognizes that 10.16 and 11.0 are equivalent.

I'm not sure what part of gdk-pixbuf2 is using python. It doesn't declare a dependency on a python port, so I guess it's using the macOS bundled python. So to benefit from any of our fixes it would need to switch to using a fixed MacPorts python.

---

Instead of changing the deployment target to 10.16 for all ports on macOS 11, we could provide an easy way for ports to individually opt into that behavior.

[jmroot (Joshua Root)]

Ticket retargeted after milestone closed

[jmroot (Joshua Root)]

I think the time where this might have been useful has passed.