Opened 4 years ago
Closed 4 years ago
#61289 closed defect (fixed)
python39 @3.9.0 : Build failure on Mac OS X Leopard due to undefined symbols
Reported by: | SerpentChris (Chris Calderon) | Owned by: | ken-cunningham-webuse |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.3 |
Keywords: | Cc: | jmroot (Joshua Root), fhgwright (Fred Wright) | |
Port: | python39 |
Description
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
Attachments (4)
Change History (14)
Changed 4 years ago by SerpentChris (Chris Calderon)
comment:1 Changed 4 years ago by fhgwright (Fred Wright)
comment:2 Changed 4 years ago by kencu (Ken)
looks like at least one of the two needed patches doesn't apply, and will need manual intervention to assess.
comment:3 Changed 4 years ago by 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...
comment:4 Changed 4 years ago by 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.
comment:5 Changed 4 years ago by fhgwright (Fred Wright)
Cc: | fhgwright added |
---|
comment:8 Changed 4 years ago by kencu (Ken)
Changed 4 years ago by kencu (Ken)
Attachment: | python39-10.4-i386-test-run.log.zip added |
---|
Changed 4 years ago by kencu (Ken)
Attachment: | python39-10.4-PPC-test-run.log.zip added |
---|
comment:9 Changed 4 years ago by 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.
Changed 4 years ago by kencu (Ken)
Attachment: | python39-10.5-PPC-test-run.log.zip added |
---|
comment:10 Changed 4 years ago by ken-cunningham-webuse
Owner: | set to ken-cunningham-webuse |
---|---|
Resolution: | → fixed |
Status: | new → closed |
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.