Pythons for PowerPC: introduce a path-style dependency and separate ports (?)

[barracuda156]

(Moving the issue to Trac.)

The issue is that Joshua is the maintainer for Pythons, and he is against accepting any PowerPC-related fixes. At the same time, there are two problems with Pythons as they are, both related to PowerPC systems:

1. Since Python 3.12, existing patch fails to work for 10.6.8 Rosetta (and developer build of 10.6 ppc). The fix is trivial and amounts to a single macro, but it is not allowed.
2. All Pythons are broken for +universal on 10.5.8 and 10.6.8. Specifically, ppc+ppc64 will fail on Leopard and i386+ppc will fail on 10.6.8. For Leopard this is a big deal. Fix for 2.7 is trivial, but not so for 3.x, where some rewrite of portfile code is needed – what we have simply does not work.

Christopher suggested a possibility of path-style dependency for Pythons. It could be a solution. Any ideas are welcome.

Please help me to get this working.

[ryandesign (Ryan Carsten Schmidt)]

Josh's reaction seems like an instance of a long-standing MacPorts tradition which is that we don't want to become the developers of the software; we just distribute it. If the software needs a change, you work with the developers of the software to get it incorporated there.

[kencu (Ken)]

python should test for pthread_threadid_np during it's configuration run, and set a define, perhaps called HAVE_PTHREAD_THREADID_NP.

I suspect that might be done in this file:

​https://github.com/python/cpython/blob/main/configure.ac

Then, if the function compiles, it can be used, otherwise it will not be used and a workaround might be used instead.

This would be a proper, maintainable, solution that does not rely on fragile arch/system assumptions.

[barracuda156]

Replying to kencu:

python should test for pthread_threadid_np during it's configuration run, and set a define, perhaps called HAVE_PTHREAD_THREADID_NP.

I suspect that might be done in this file:

​https://github.com/python/cpython/blob/main/configure.ac

Then, if the function compiles, it can be used, otherwise it will not be used and a workaround might be used instead.

This would be a proper, maintainable, solution that does not rely on fragile arch/system assumptions.

Your idea is indeed better than tweaking an existing patch.

[jmroot (Joshua Root)]

Replying to barracuda156:

The issue is that Joshua is the maintainer for Pythons, and he is against accepting any PowerPC-related fixes.

Please don't misrepresent; I have not refused any reasonable fixes for 10.4/10.5 ppc.

2. All Pythons are broken for +universal on 10.5.8 and 10.6.8. Specifically, ppc+ppc64 will fail on Leopard and i386+ppc will fail on 10.6.8. For Leopard this is a big deal. Fix for 2.7 is trivial, but not so for 3.x, where some rewrite of portfile code is needed – what we have simply does not work.

IIRC ppc+ppc64 was never a supported universal combination for python.

Christopher suggested a possibility of path-style dependency for Pythons. It could be a solution.

Requiring all dependent ports to make a change is unlikely to be more acceptable.