python39 @3.9.0 : Build failure on Mac OS X Leopard due to undefined symbols

[SerpentChris (Chris Calderon)]

This build failure looks similar to comments on the old Python38 build failure on Mac OS X Leopard, #59827. I'm guessing Python 3.9 needs a similar patch?

/usr/bin/gcc-4.2 -o Python.framework/Versions/3.9/Python -L/opt/local32/lib -Wl,-headerpad_max_install_names -arch ppc    -dynamiclib \
		-all_load libpython3.9.a -Wl,-single_module \
		-install_name /opt/local32/Library/Frameworks/Python.framework/Versions/3.9/Python \
		-compatibility_version 3.9 \
		-current_version 3.9 \
		-framework CoreFoundation -lintl -ldl   -framework CoreFoundation;
Undefined symbols:
  "_pthread_threadid_np", referenced from:
      _PyThread_get_thread_native_id in libpython3.9.a(thread.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [Python.framework/Versions/3.9/Python] Error 1

[fhgwright (Fred Wright)]

It also fails on Tiger, due to COPYFILE_DATA being undefined. As with the Leopard issue, python38 had a patch for this that wasn't carried forward.

[kencu (Ken)]

looks like at least one of the two needed patches doesn't apply, and will need manual intervention to assess.

[kencu (Ken)]

fixed the patches. I'll run some tests and throw up a PR pretty soon.

Not like we are in a gawdaful holy rush to get a one-week-old python on a 16 year old OS anyway, ... but I digress...

[fhgwright (Fred Wright)]

I'd started investigating this before noticing the python38 patches, and it seems that a one-line patch is sufficient to convince it that native thread naming doesn't exist prior to 10.6. I don't know if anything more elaborate than that is really needed.

Similarly, a one-line patch is sufficient to get rid of the COPYFILE_DATA reference, though the consequences of disabling the corresponding Python definition (including in shutil and test_shutil) would need to be investigated. I do notice that the "fast copyfile" mechanism isn't expected to be available on all OSes, according to the Python docs.

A recurring problem with 10.4, affecting Python and Ruby at least, is that it implements the fcopyfile() function, but not the COPYFILE_DATA option for it.

[kencu (Ken)]

I already have it fixed. Just finishing off the tests.

[kencu (Ken)]

Fred -- if you have extra time on your hands, please go back and do the proper fix to the Ruby ports. I put them all here, BTW <​https://github.com/kencu/TigerPorts/tree/master/lang>.

[kencu (Ken)]

PR <​https://github.com/macports/macports-ports/pull/8737>

[kencu (Ken)]

Those test runs are with the fixes in the referenced PR. Anyone who can contribute fixes that improve on those test runs on Tiger, much appreciated. Leopard to follow.

[ken-cunningham-webuse]

In 7661cbbd19348b73cfc7f49d04eb601134598022/macports-ports (master):

python39: fix build on older systems

similar to fix for python38
closes #61289