homepage

_ctypes.dlopen is not including the errno when it raises OSError.
This occurs when attempting to load a library that doesn't exist, the error string given is clearly generated from an ENOENT.
joiner@dbssyd800:~$ python3 dlopen_raise.py
None
somelib.so: cannot open shared object file: No such file or directory

On Windows:
>>> try:
... ctypes.CDLL('somelib')
... except OSError as exc:
... print repr(exc)
... print exc.errno
...
WindowsError(126, 'The specified module could not be found')
22

Should I just submit a patch for this myself? Can someone confirm the behaviour is incorrect so I don't waste time fixing it?

At least in Windows, the exception object has its `winerror` attribute correctly set to 126, which is also translated to POSIX `errno` with `winerror_to_errno()`; the latter gives us EINVAL (22).

From what I gather from the code, when dlopen fails in POSIX platforms, ctypes raises an PyExc_OSError instantiated with a simple string (via PyErr_SetString()). I suppose this could be changed to raise a more complex tuple, instead (like its WindowsError equivalent when LoadLibrary fails in Windows platforms), but that might break existing code that relies on this behavior. 3.3 only?

Not sure how this can be fixed actually. I don't think PyErr_SetFromErrno instead of PyErr_SetString would work because as far as I can tell, standard does not mention dlopen making use of errno. Unlike Windows, where LoadLibrary will change last-error, if dlopen fails, only way to retrieve error is to dlerror which returns a string, no error code.

Indeed, it looks more like a bug in the POSIX standard unfortunately.
I'm suggesting to close as "won't fix".

I didn't notice there was no use of errno. It's quite possible that dlopen might be used without the C library present, so perhaps this is why it wasn't included. The error strings however are very C-like, which made me think of this in the first place. Thanks all.