Issue15498
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2012-07-30 07:34 by ned.deily, last changed 2022-04-11 14:57 by admin.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
issue15498-v1.txt | ronaldoussoren, 2012-07-31 12:03 | review |
Messages (4) | |||
---|---|---|---|
msg166863 - (view) | Author: Ned Deily (ned.deily) * | Date: 2012-07-30 07:34 | |
getpath.c uses three OS X APIs that have been producing deprecation warnings since at least OS X 10.5: NSModuleForSymbol, NSLookupAndBindSymbol, and NSLibraryNameForModule. We should figure out how to live without them. |
|||
msg166991 - (view) | Author: Ronald Oussoren (ronaldoussoren) * | Date: 2012-07-31 12:03 | |
Removing the dependency on NSLookupAndBindSymbol (and related APIs) is easier than I expected. The attached patch (issue15498-v1.txt) uses dladdr to get symbol information for Py_Initialize and that information includes the path for the library where that symbol is located (that is the framework). The patch has seen only light testing, in particular: I've verified that the library path has the expected value, but haven't run the full test suite set. TODO: - Run test full test suite with a framework build (both before and after installing) - Likewise for a regular unix build - Likewise for a regular unix build with --enable-shared This patch should work on OSX 10.4 or later, and may also work on OSX 10.3, the manpage for dladdr is not entirely clear on whether or not the symbol is available in libSystem on OSX 10.3. |
|||
msg173828 - (view) | Author: Ronald Oussoren (ronaldoussoren) * | Date: 2012-10-26 09:17 | |
Apple seems to have switched to using dlopen in their version of getpath.c (see <http://www.opensource.apple.com/source/python/python-60.3/2.7/fix/getpath.c.ed>, this is the version in OSX 10.8.2) This causes a problem for some people, as noticed on the pythonmac mailing list. This is something we should test before applying my patch to avoid regressions. Message-Id: <508951D3.7080805@llnl.gov> says: I am trying to work with Apple Mountain Lion's install of Python 2.7. I have a language interoperability tool, Babel http://www.llnl.gov/CASC/components/, that used embedded Python when other languages are calling Python (c.g., C++ calling Python). My fundamental problem is that sys.path is not being initialized the same when I dlopen(libpython2.7.dylib) and initialize Python compared with how the sys.path is set when the Python executable is called directly. This causes Python to fail to load the numpy module used by Babel. bash-3.2$ /usr/bin/python2.7 -c "import sys; print sys.path; import numpy"> /tmp/out1 bash-3.2$ /usr/bin/python -c "import sys; print sys.path; import numpy" /tmp/out2 bash-3.2$ cat /tmp/out1 ['', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload', '/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC', '/Library/Python/2.7/site-packages'] bash-3.2$ diff /tmp/out1 /tmp/out2 bash-3.2$ ls -al /usr/bin/python2.7 lrwxr-xr-x 1 root wheel 75 Aug 23 11:10 /usr/bin/python2.7 -> ../../System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7 Presumably, this C program that uses dlopen(), Py_Initialize, and Py_SimpleString should have exactly the same output. /** foo.c */ #include<dlfcn.h> #include<stdio.h> int main(int argc, char **argv) { // void *lptr = dlopen("/System/Library/Frameworks/Python.framework/Python", RTLD_NOW | RTLD_GLOBAL); void *lptr = dlopen("/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib", RTLD_NOW | RTLD_GLOBAL); if (lptr) { void (*pyinit)(void) = dlsym(lptr, "Py_Initialize"); if (pyinit) { int (*runSimple)(const char *); (*pyinit)(); /* initialize Python */ runSimple = dlsym(lptr, "PyRun_SimpleString"); if (runSimple) { (*runSimple)("import sys ; print sys.path; import numpy"); } } else { fprintf(stderr, "Unable to locate Py_Initialize: %s\n", dlerror()); } } else { fprintf(stderr, "Error loading Python shared library: %s\n", dlerror()); } } bash-3.2$ gcc foo.c ; ./a.out ['/usr/lib/python27.zip', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-darwin', '/usr/lib/python2.7/plat-mac', '/usr/lib/python2.7/plat-mac/lib-scriptpackages', '/usr/Extras/lib/python', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload'] Traceback (most recent call last): File "<string>", line 1, in<module> ImportError: No module named numpy However as you see, it has a completely different sys.path. I can't seem to find a way to get it to initialize Python with the same sys.path. It seems like the libpython2.7.dylib is broken. I am at a loss on how to fix this or even who to ask for help. |
|||
msg354378 - (view) | Author: STINNER Victor (vstinner) * | Date: 2019-10-10 14:02 | |
The deprecation warnings are not fixed yet. They were quickly mentioned at: https://bugs.python.org/issue38429#msg354367 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:33 | admin | set | github: 59703 |
2021-11-27 11:57:12 | iritkatriel | set | versions: + Python 3.11, - Python 3.4 |
2019-10-10 14:02:14 | vstinner | set | nosy:
+ vstinner messages: + msg354378 |
2012-10-26 09:17:32 | ronaldoussoren | set | messages: + msg173828 |
2012-07-31 12:03:03 | ronaldoussoren | set | keywords:
+ needs review files: + issue15498-v1.txt messages: + msg166991 stage: needs patch -> patch review |
2012-07-30 07:34:24 | ned.deily | create |