- Notifications
You must be signed in to change notification settings - Fork126
Passing arch to the nix install script and adjusting brew libs + use macos-14 to build if needed#277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…options for 3.11+-with-tcl-tk-xxx configure options removed in python 3.11.0, use env varshttps://github.com/python/cpython/blob/762f489b31afe0f0589aa784bf99c752044e7f30/Doc/whatsnew/3.11.rst#L2167-L2172tcl-tk includes are in a subdir on recent homebrew recipehttps://github.com/pyenv/pyenv/blob/0167890c8c8e66bb1aaa579725a27279d31afb96/plugins/python-build/bin/python-build#L1679C7-L1687
There are several issues if it ends up building:* The toolcache location is wrong* It links to x64 libs, like /usr/local/opt/libintl
I cannot **link** to the resulting python dylib otherwise.
@jmarrec, why the change from always using universal2 installers on arm64 ? |
| if (($this.Version-ge$PkgVersion)-or ($this.Architecture-eq"arm64")) { | ||
| if (($this.Version-ge$PkgVersion)-and ($this.Architecture-eq"x64")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
arm64 always uses the universal2 installer.
most of the changes here are not required if this stays the same.
I cannot properly link a c++ executable to it if using the universal installer. |
that seems like a different issue. universal2 installer provides dual arch (x86_64 & arm64). Do you have a repro for this ? |
Not that simple to provide a MCVE, but I've experienced it in a (large) project that uses CMake and CPack for packaging, and which redistributes the python dylib. Linking is ok, the issue is when executing it. It refuses to launch it due to code signature I think. |
@mayeut here is a MCVE repro:https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106 It's not impossible that this could be the issue:https://stackoverflow.com/questions/58997650/trying-to-codesign-a-mac-osx-app-but-when-i-check-it-i-get-pharo-app-invalid The SO post mentions that codesign behaves differently when you have a library/exe that starts with an uppercase, and the resolved python library is Anyways, the program links, but can't be executed. https://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017370106#step:7:15 And the relevant build warning athttps://github.com/jmarrec/test-Github-Actions/actions/runs/9446808318/job/26017246804#step:6:2196 And here is a run with my fork for setup-python, which uses my fork of python-versions where I force build the python package on mac https://github.com/jmarrec/test-Github-Actions/actions/runs/9446912815 |
Uh oh!
There was an error while loading.Please reload this page.
The commit descriptions provide more info.