guix-devel
[Top][All Lists]
Advanced

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

Re: next browser (was: Packaging a free Firefox)


From: Ricardo Wurmus
Subject: Re: next browser (was: Packaging a free Firefox)
Date: Thu, 24 May 2018 17:33:48 +0200
User-agent: mu4e 1.0; emacs 25.3.1

Hi Pierre,

> Ricardo Wurmus <address@hidden> writes:
>
>>> The main issue is with cffi: it does not find the libraries installed by 
>>> Guix.
>> […]
>>
>> I don’t understand this.  Should it load any libraries that the user may
>> have installed?  Or do you only refer to a specific set of libraries
>> that is known at build time?
>
> Sorry for the confusing report, I suppose it needs more details: cffi is
> the "common foreign function interface" for Common Lisp.  It allows for
> writing bindings to libraries written in different languages (mostly C
> as far as I understand).
>
>       http://common-lisp.net/project/cffi
>
> cffi-based projects like Next load libraries at runtime (in
> this case .so files).  No special provision is taken for finding those
> libaries, or at least nothing I could spot from the source code.  I
> understand that it relies on system calls.  But while
> dlopen("libsqlite3.so") works in C, cffi fails to load "libsqlite3.so",
> unless we specify an appropriate LD_LIBRARY_PATH.

It is sometimes possible to patch the sources by replacing the library
name with the full path of the library.  Have you tried that?

Another option is to wrap the executable in LD_LIBRARY_PATH, although
that should only be a last resort.

> GuixSD has LIBRARY_PATH=~/.guix-profile/lib, can we use that?

LIBRARY_PATH is only set when you have gcc-toolchain installed.  I don’t
have this variable.  It is also not applicable here: it is used by the
compiler at build time when linking applications.

--
Ricardo





reply via email to

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