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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library #55654
Comments
I routinely configure Python like so on my Mac (10.5.8):
This has always worked for me. Now, after installing from my Mercurial
Here it is when installed from a Mercurial sandbox:
Note that every directory in sys.path involving <prefix> has been completely I've confirmed that identical configure commands were used for both the svn Skip |
Are you sure you're not really using the MacPorts python? What's the value of sys.executable? |
Ned> Are you sure you're not really using the MacPorts python? What's Yup, pretty sure. :-) Here it is run from my hg sandbox: % pwd
/Users/skip/src/hgpython/2.7
% ./python.exe
Python 2.7.1 (r271:86832, Feb 2 2011, 06:56:19)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.executable
'/Users/skip/src/hgpython/2.7/python.exe'
>>> sys.path
['/Users/skip/misc/python/python2', '/Users/skip/misc/python', '', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/Users/skip/.local/lib/python2.7/site-packages', '/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages'] Skip |
I can reproduce this. Chances are you'll see that the python.exe has been dynamically linked to the MacPorts Python instead of the just produced libpython2.7.dylib : $ otool -L ./python.exe
./python.exe:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) No doubt you can work around it by removing the --enable-shared and/or removing the MacPorts Python2.7 from the picture. It's not yet clear to me why it's getting linked that way (--enable-shared on OS X doesn't get tested all that much as we normally do framework builds) but I'm very doubtful it has anything directly to do with hg vs svn checkout. |
Ned> No doubt you can work around it by removing the --enable-shared I don't rightly recall why I use --enable-shared, but hopefully I can get Any idea why --enable-shared didn't hose up my svn sandbox build? Skip |
I take that back. I looked in config.status. I didn't use --enable-shared So, it's clearly the --enable-shared that's the culprit. The library search Would be nice if we could fix that. I can't see why a third party library S |
It is --enable-shared that is the culprit, but in the negated form... The OSX linker will search the entire link path for a shared library before trying to look for a static library. As a workaround you could use '--enable-shared', and that should ensure that you get linked to the python version you're actually building as it is earlier on the path. A proper fix is to add "-Wl,-search_paths_first" to the linker flags on OSX, with that flag the linker behaves just like the linker on any other unix platform. |
I see the problem now. Using a --enable-shared configure similar to Skip's, the gcc step that builds python.exe is: gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \ What I failed to notice originally is that the MacPorts python27 port, which both Skip and I have installed, adds a link in /opt/local/lib to its framework lib: /opt/local/lib/libpython2.7.dylib@ -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Python So since /opt/local/lib comes first on the lib list, that libpython2.7 is going to be found before the build directory's dylib. Moving -L /opt/local/lib to after -L. does seem to fix the problem. In the non-shared case, the gcc link step is: gcc -L/opt/local/lib -u _PyMac_Error -o python.exe \ so the local static lib is explicitly loaded and there shouldn't be a problem. The shared-lib case is nasty in that you can easily link to the wrong lib without realizing it. The Makefile (for 2.7 - py3k is similar) is: # Build the interpreter I wonder whether |
The attached patch fixes the issue by moveing LDFLAGS after BLDLIBRARY in the linking step. I'm not committing this yet though as this will affect all platforms that use Makefiles to build, and I'm not sure if this change save for all compilers we effectively support. Fixing this completely for OSX will require another change as well: we'd have to add "-Wl,-search_paths_first" to ensure that the build will pick up the first libpython on the search path, otherwise we'd still have a problem if you try to build a staticly linked binary (as this would still cause the linker to find macports if the additional flag isn't used). |
|
I've attached an updated patch (against the 2.7 branch, the same idea should work for 3.3 and default). This does two things:
This should work fine on OSX (obviously) and Linux, but I'm not 100% that (Adding 3.3 and 3.4 to the versions because those should also be affected by this issue) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: