[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 ?
pgpPL4tQ6wJ9q.pgp
Description: OpenPGP digital signature