[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.11 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c

[STINNER Victor]

STINNER Victor  added the comment:

The deprecation warnings are not fixed yet. They were quickly mentioned at:
https://bugs.python.org/issue38429#msg354367

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c

[Ronald Oussoren]

Ronald Oussoren added the comment:

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.7080...@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 */
#includedlfcn.h
#includestdio.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, inmodule
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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15498
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c

[Ronald Oussoren]

Ronald Oussoren added the comment:

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.

--
keywords: +needs review
stage: needs patch - patch review
Added file: http://bugs.python.org/file26622/issue15498-v1.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15498
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c

[Ned Deily]

New submission from Ned Deily:

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.

--
assignee: ronaldoussoren
components: Macintosh
messages: 166863
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate the use of deprecated OS X APIs in getpath.c
versions: Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15498
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com