guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (python) ctypes.util.find_library full path ?


From: Danny Milosavljevic
Subject: Re: (python) ctypes.util.find_library full path ?
Date: Sun, 24 Feb 2019 20:02:33 +0100

Hi zimoun,

On Fri, 22 Feb 2019 15:51:17 +0100
zimoun <address@hidden> wrote:

> However, the command `weasyprint` fails at run time. Because an issue
> about `dlopen'.
> 
> To be precise, and from my understanding, the culprit is these lines:
> https://github.com/Kozea/cairocffi/blob/v1.0.2/cairocffi/__init__.py#L30-L31
> 
> In other word, ctypes.util.find_library('cairo') returns the expected
> 'libcairo.so.2'.
> But then it is not recognized by their `ffi.dlopen`.
> And if the full path is provided then it works, e.g.,
>  
> ffi.dlopen('/gnu/store/13i02w6r4awyb5d4n8plk8m0idvryib0-cairo-1.14.12/lib/libcairo.so.2')
>  <Lib object for
> '/gnu/store/13i02w6r4awyb5d4n8plk8m0idvryib0-cairo-1.14.12/lib/libcairo.so.2'>

> My questions is: is there a fix for this kind of issue ?
> I guess, it should happen with Python packages.
> 
> If yes, what is the trick ?
> If no, what should be the trick ? What do you think ?

One possibility:

(1) Make the guix package patch the file cairocffi/__init__.py in order
to make it pass the correct path to cairo.so.2 to dlopen. Furthermore,
make it remove the call to ctypes.util.find_library (replace by "do nothing").

The other possibility is to

(2) wrap weasyprint so LD_LIBRARY_PATH is set up.

In this case, since python-cairocffi is presumably also used by others,
set it up to do (1).  But I checked guix master, the package
"python-cairocffi" there is already set up for (1).

Are you sure you didn't accidentially create a duplicate that doesn't?

Are you sure that the culprit isn't in python-cairosvg ?

Attachment: pgpPL4tQ6wJ9q.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]