python310: fix universal build on older systems

[MarcusCalhoun-Lopez]

It seems that the build system assumes that the default compiler
build architecture is the same as the default run architecture.

Revbump is needed since the universal build can be incorrect
on older systems.

Description

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.5.8 9L31a i386
Xcode 3.1.4 9M2809

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint --nitpick?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@jmroot for port python310.

[jmroot]

This seems backwards at first glance. Can you give more details on what problem this is solving, and how?

[MarcusCalhoun-Lopez]

Sorry, this is not a proper solution solution.

On a 10.5 VM, a i386/x86_64 universal Python build is not correct.
python3.10 -c "import hashlib;m=hashlib.md5();print(m.hexdigest())" fails:

ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/hashlib.py", line 261, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/hashlib.py", line 123, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)

During the build process, the following seems to be the problem:

building '_md5' extension
/usr/bin/gcc-4.2 -fno-strict-aliasing -Wsign-compare -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I./Include -I. -I/opt/local/include -I/opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4/Include -I/opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4 -c /opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4/Modules/md5module.c -o build/temp.macosx-10.5-x86_64-3.10/opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4/Modules/md5module.o
/usr/bin/gcc-4.2 -bundle -undefined dynamic_lookup -arch i386 -arch x86_64 -L/opt/local/lib -Wl,-headerpad_max_install_names -arch i386 -arch x86_64 build/temp.macosx-10.5-x86_64-3.10/opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4/Modules/md5module.o -L/opt/local/lib -o build/lib.macosx-10.5-x86_64-3.10/_md5.cpython-310-darwin.so
ld warning: in build/temp.macosx-10.5-x86_64-3.10/opt/local/var/macports/build/_Users_macports_MacPorts_mports_lang_python310/python310/work/Python-3.10.4/Modules/md5module.o, file is not of required architecture

Oddly, building '_md5' extension is run twice.
Once correctly and the second time, not.

More research seems to be in order.

[jmroot]

That looks like the same thing as Trac #63782. Modules are rebuilt during the destroot phase, after the -arch flags are stripped out of the config. I wasn't yet able to determine how the build system is deciding that the rebuild is needed (and thus how to prevent it).

[MarcusCalhoun-Lopez]

@jmroot, thank you for the link.
I believe Trac #63782 may be the same problem.
I moved the patch of _sysconfigdata__darwin_darwin.py from post-build to post-destroot.
That fixed my problem.
I will have to test a little more before it can be determined if it fixes the ticket as well.

Do you think this pull request might be headed in the right direction?

[jmroot]

The problem with making the modification in post-destroot is that the .pyc won't match the .py.

[MarcusCalhoun-Lopez]

In the pull request, there is code in the post-destroot which should update the .pyc files:

system -W ${destroot}${framewdir} "env DYLD_LIBRARY_PATH=. bin/python3 -m compileall -o 0 -o 1 -o 2 lib/python${branch}/_sysconfigdata__darwin_darwin.py"

[jmroot]

I see, that would indeed be a better solution. Unfortunately it doesn't seem to work in its current form:

2022-05-09T23:57:51.7371820Z DEBUG: system -W /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_lang_python310/python310/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/3.10: env DYLD_LIBRARY_PATH=. bin/python3 -m compileall -o 0 -o 1 -o 2 lib/python3.10/_sysconfigdata__darwin_darwin.py
2022-05-09T23:57:51.9917470Z dyld: Library not loaded: /opt/local/Library/Frameworks/Python.framework/Versions/3.10/Python
2022-05-09T23:57:51.9919180Z   Referenced from: /opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_lang_python310/python310/work/destroot/opt/local/Library/Frameworks/Python.framework/Versions/3.10/bin/python3
2022-05-09T23:57:51.9920940Z   Reason: image not found
2022-05-09T23:57:51.9921890Z Command failed: env DYLD_LIBRARY_PATH=. bin/python3 -m compileall -o 0 -o 1 -o 2 lib/python3.10/_sysconfigdata__darwin_darwin.py
2022-05-09T23:57:51.9923020Z Killed by signal: 6
2022-05-09T23:57:51.9925070Z Error: Failed to destroot python310: command execution failed

[MarcusCalhoun-Lopez]

I see, that would indeed be a better solution. Unfortunately it doesn't seem to work in its current form:

Thanks for checking.
I only tested on an older system.
I will test on more recent systems.

[jmroot]

I added an attempted fix, we'll see if CI succeeds.

[jmroot]

OK, looks good.

[jmroot]

There was a problem with case-sensitive filesystems, but I've fixed that now, and it looks like all platforms are green on buildbot. Thanks Marcus!