boost: backport fix for context from boost181

[barracuda156]

Boost context has been somewhat better fixed in: ​https://github.com/macports/macports-ports/pull/17086 It remains broken in earlier versions.

This makes it impossible to build some ports for ppc (ex., folly).

[ryandesign (Ryan Carsten Schmidt)]

There is also some commentary on this commit requesting that the default boost version be updated for Darwin 9 and earlier.

Changing the default version of boost in the boost portgroup would change the dependencies of every port that uses the boost portgroup and does not specify the boost version, and it might cause those ports to fail to build since boost versions are ​inherently not backward compatible; that's the whole reason why we offer multiple boost ports.

So if we want to change the default boost version in the boost portgroup, we have to simultaneously make one of two changes in every port that uses the boost portgroup and does not specify the boost version: either revbump and verify it still builds and works with the new boost version, or modify the port to specify the old formerly-default boost version.

That would be a large amount of work to do at once, so I would be in favor of an approach where, for every port that uses the boost portgroup and does not specify the boost version, we modify them, gradually over time (for example when updating them to a new version) so that they specify the boost version. Then eventually we can remove the default boost version from the boost portgroup, ensuring that every port that subsequently uses the boost portgroup will have to specify the boost version.

[mascguy (Christopher Nielsen)]

Replying to ryandesign:

So if we want to change the default boost version in the boost portgroup, we have to simultaneously make one of two changes in every port that uses the boost portgroup and does not specify the boost version: either revbump and verify it still builds and works with the new boost version, or modify the port to specify the old formerly-default boost version.

That would be a large amount of work to do at once, so I would be in favor of an approach where, for every port that uses the boost portgroup and does not specify the boost version, we modify them, gradually over time (for example when updating them to a new version) so that they specify the boost version. Then eventually we can remove the default boost version from the boost portgroup, ensuring that every port that subsequently uses the boost portgroup will have to specify the boost version.

Yes, compared to all of that, applying the context fix - assuming the same patch can be used verbatim (?) for 1.76 to 1.80 - is downright trivial.

So Sergey, if you want to submit a PR with that change for 1.76 to 1.80, that's certainly fine. Particularly if it only affects PPC builds.

[barracuda156]

Replying to mascguy:

Replying to ryandesign:

So if we want to change the default boost version in the boost portgroup, we have to simultaneously make one of two changes in every port that uses the boost portgroup and does not specify the boost version: either revbump and verify it still builds and works with the new boost version, or modify the port to specify the old formerly-default boost version.

That would be a large amount of work to do at once, so I would be in favor of an approach where, for every port that uses the boost portgroup and does not specify the boost version, we modify them, gradually over time (for example when updating them to a new version) so that they specify the boost version. Then eventually we can remove the default boost version from the boost portgroup, ensuring that every port that subsequently uses the boost portgroup will have to specify the boost version.

Yes, compared to all of that, applying the context fix - assuming the same patch can be used verbatim (?) for 1.76 to 1.80 - is downright trivial.

So Sergey, if you want to submit a PR with that change for 1.76 to 1.80, that's certainly fine. Particularly if it only affects PPC builds.

We could do that, sure.

Perhaps let us try fixing ppc64 first? So that we do not need an extra PR affecting every Boost version.

16. S. Reminder to myself and FYI: there are several fixes to backport in order for old Boost to be as usable as newer ones:
17. Fixes for ppc (and hopefully ppc64) libcontext.
18. Fix for fiber.
19. Fix for multiprecision header inclusion.
20. Fix for atomics.

All of these are PPC-only, yes. Boost 1.80 is broken with GCC, I believe, so a fix for that may be also backported from 1.81 (this is not PPC-specific).