Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #112199 > unrolled thread

ctypes Usage Note

Back to article view | Back to comp.lang.python

Contents

  ctypes Usage Note Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-08-01 18:41 -0700
    Re: ctypes Usage Note eryk sun <eryksun@gmail.com> - 2016-08-02 05:17 +0000
      Re: ctypes Usage Note Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-08-01 23:46 -0700
        Re: ctypes Usage Note Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-08-03 19:22 -0700
    Re: ctypes Usage Note Nobody <nobody@nowhere.invalid> - 2016-08-02 23:13 +0100

#112199 — ctypes Usage Note

Sometimes people load a library with ctypes like this:

    libc = ctypes.cdll.LoadLibrary("libc.so")

Don’t do that. Do this instead:

    libc = ctypes.cdll.LoadLibrary("libc.so.6")

What’s the difference? The difference is that the unversioned library comes from the “development” package, while the versioned one comes from the “runtime” package. Users of your Python binding should only need to have the runtime package installed to run scripts that use it, not the development package.

So: always load the explicitly-versioned library name.

I thnk this recommendation should be part of the official ctypes docs <https://docs.python.org/3/library/ctypes.html>, don’t you?

[toc] | [next] | [standalone]

#112204

On Tue, Aug 2, 2016 at 1:41 AM, Lawrence D’Oliveiro
<lawrencedo99@gmail.com> wrote:
>
> Don’t do that. Do this instead:
>
>     libc = ctypes.cdll.LoadLibrary("libc.so.6")

I recommend using ctypes.CDLL instead. ctypes.cdll is pretty much
pointless on Unix systems (and a potential problem on Windows due to
cached function pointers). It also doesn't allow passing the mode,
handle, and use_errno parameters.

As to the library name, you may instead want to use find_library for
Unix shared libraries:

    >>> ctypes.util.find_library('c')
    'libc.so.6'
    >>> ctypes.util.find_library('python3.5m')
    'libpython3.5m.so.1.0'

It's pretty much pointless on Windows since it just searches PATH for
the given name. It doesn't match how Windows LoadLibrary(Ex) really
works, which allows precise control over exactly what gets searched
via AddDllDirectory, SetDefaultDllDirectories, and activation contexts
(i.e. ActivateActCtx). Plus find_library('c') no longer even works in
3.5+ on Windows (it returns None) because the CRT has been split into
API sets (currently all mapped to ucrtbase.dll, but presumably that
can change with servicing).

[toc] | [prev] | [next] | [standalone]

#112205

On Tuesday, August 2, 2016 at 5:18:14 PM UTC+12, eryk sun wrote:

> I recommend using ctypes.CDLL instead. ctypes.cdll is pretty much
> pointless on Unix systems (and a potential problem on Windows due to
> cached function pointers). It also doesn't allow passing the mode,
> handle, and use_errno parameters.

None of which I currently care about.

[toc] | [prev] | [next] | [standalone]

#112314

On Tuesday, August 2, 2016 at 6:46:45 PM UTC+12, I wrote:

> On Tuesday, August 2, 2016 at 5:18:14 PM UTC+12, eryk sun wrote:
> 
>> I recommend using ctypes.CDLL instead. ctypes.cdll is pretty much
>> pointless on Unix systems (and a potential problem on Windows due to
>> cached function pointers). It also doesn't allow passing the mode,
>> handle, and use_errno parameters.
> 
> None of which I currently care about.

Actually, thinking about it, there might be a point to specifying RTLD_GLOBAL. Which makes me wonder: why isn’t it the default?

As for errno, that’s an egregious piece of POSIX brain damage. You’ll notice that just about nothing else uses it, apart from (the various implementations of) libc, which have to.

[toc] | [prev] | [next] | [standalone]

#112256

On Mon, 01 Aug 2016 18:41:53 -0700, Lawrence D’Oliveiro wrote:

> Sometimes people load a library with ctypes like this:
> 
>     libc = ctypes.cdll.LoadLibrary("libc.so")

That specific example is unlikely to work on any modern Linux system, as
libc.so is typically a linker script rather than a symlink to a DSO.
Likewise for libm and libpthread.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web