-
-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
[doc] ctypes: use_errno=True does not work #52008
Comments
On my system (Ubuntu Karmic, Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15), Kernel 2.6.31-17-generic, libc6 2.10.1-0ubuntu16) the attached test script produces the following output: Traceback (most recent call last):
File "test1.py", line 27, in <module>
raise OSError(err, os.strerror(err), path)
OSError: [Errno 0] Success: '/does/not/exist' So the function call failed, but the errno provided by ctypes is zero. (There are two variants of construction the getxattr() foreign function in the script and both produce the same result). |
In the libc case you shouldn't give absolute path in CDLL: CDLL('libc.so.6') is better. You use "/lib/libc.so.6" path, but Python (and ctypes.so) actually uses something like "/lib/tls/i686/cmov/libc.so.6" - these are two separate libraries with separate "errno" variables, mapped to different memory regions. Your call to getxattr modifies errno in the former library, but ctypes get_errno() fetches value from the latter library. If I fix CDLL() call, the test works ok for me. |
I can confirm that without the path it works for me too. But I have to admit that I don't really understand your explanation. Should I generally not use full paths with CDLL? Or just in the case of libc? In either case, I think the ctypes dokumentation could be more explicit about this. |
Would someone like to propose a documentation patch that clarifies this situation. |
Is this really a documentation issue? Is it not generally understood that using absolute paths to libraries is a bad idea due to the amount of PATH/symlink spaghetti that the average file system contains? |
Matt, I believe in that case it's still a documentation issue, because then the documentation probably should say that using absolute paths to libraries is a bad idea in general. |
The recommendation not to use absolute paths in CDLL is still not mentioned in the docs: Adding the (active) ctypes experts to nosy. |
It's not generally the case. Load just a base filename only if the shared library is in the loader's search path. Otherwise use a qualified path that contains at least one path separator (e.g. "./library.dll"). |
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: