(python) ctypes.util.find_library full path ?

(python) ctypes.util.find_library full path ?

[zimoun]

Dear,

I would like to try WeasyPrint [1] to convert some HTML docs to PDF
ones and maybe print them. Or maybe presentation etc.

[1] https://weasyprint.org/

Well, excluding the check phase at first because some dependencies
does not seem clean with Python2/Python3. Anyway!

it is almost straightforward with `guix import pypi -r weasyprint'. Awesome !
(there is some tweaks in url: "cairosvg" -> "CairoSVG")

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'>

There is an old "similar" issue on the bug Nix tracker #7307 [2],
asking if `ctypes.util.find_library` should return full path (so apply
somehow a patch) or add another env variable. I do not know what is
the status now.

[2] https://github.com/NixOS/nixpkgs/issues/7307


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 ?


Thank you for any pointer and/or comments.


All the best,
simon

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

[Alex Vong]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

Hello simon,

I don't know if there's an easier fix. But what I would do is to add a
'wrap-program' phase and use the 'wrap-program' procedure to create a
wrapper to set the required environment variable at run-time. My guess
is that 'LD_LIBRARY_PATH' should be set to:

  (string-append (assoc-ref inputs "cairo") "/lib")

Examples can be found in '(gnu packages bioinformatics)'.

Cheers,
Alex

zimoun <zimon.toutoune@gmail.com> writes:

> Dear,
>
> I would like to try WeasyPrint [1] to convert some HTML docs to PDF
> ones and maybe print them. Or maybe presentation etc.
>
> [1] https://weasyprint.org/
>
> Well, excluding the check phase at first because some dependencies
> does not seem clean with Python2/Python3. Anyway!
>
> it is almost straightforward with `guix import pypi -r weasyprint'. Awesome !
> (there is some tweaks in url: "cairosvg" -> "CairoSVG")
>
> 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'>
>
> There is an old "similar" issue on the bug Nix tracker #7307 [2],
> asking if `ctypes.util.find_library` should return full path (so apply
> somehow a patch) or add another env variable. I do not know what is
> the status now.
>
> [2] https://github.com/NixOS/nixpkgs/issues/7307
>
>
> 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 ?
>
>
> Thank you for any pointer and/or comments.
>
>
> All the best,
> simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[zimoun]

Dear Alex,

On Sat, 23 Feb 2019 at 16:39, Alex Vong <alexvong1995@gmail.com> wrote:
>
>   (string-append (assoc-ref inputs "cairo") "/lib")
>
> Examples can be found in '(gnu packages bioinformatics)'.

Thank you for the pointer.
I am diving... I think I get the point. :-)


All the best
--
simon

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

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]

Hi zimoun,

On Fri, 22 Feb 2019 15:51:17 +0100
zimoun <zimon.toutoune@gmail.com> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[zimoun]

Hi Danny,

Thank you for your explanations.

On Sun, 24 Feb 2019 at 20:02, Danny Milosavljevic
<dannym@scratchpost.org> wrote:
>
> 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?

Yes, there is a duplicate here.
I naively thought that `guix import pypi -r tool` was checking if the
dependency was or not already declared.

The good point is I have learned about the issue and how to fix it. :-)

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

Now, the culprit is python-cffi with a similar error than the previous one.
Well, I post-pone that to come back later with fresh eyes. ;-)


Thank you again for your explanations.


All the best
--
simon