Ricardo Wurmus <rekado@elephly.net> 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.

I'm not quite sure how applications find libraries on GuixSD.

>> --8<---------------cut here---------------start------------->8---
>> LISP?=sbcl
>>
>> build-gtk:
>> 	$(LISP) \
>> 		--eval '(ql:quickload :cffi)' \
>> 		--eval '(push (format nil "~a/.guix-profile/lib/" (uiop:getenv "HOME")) cffi:*foreign-library-directories*)' \
>>     ## Rest is as usual.
>> 		--load next.asd \
>> 		--eval '(ql:quickload :next/gtk)' \
>> 		--eval '(asdf:make :next/gtk)' \
>> 		--eval '(quit)'
>> --8<---------------cut here---------------end--------------->8---
>
> This would not be good, because packages can be installed in different
> profiles, not only in the user’s home directory.

Indeed, but I don't know a better solution.  Any idea how to do this
properly?

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

-- 
Pierre Neidhardt