From: Josef W. <jw...@ra...> - 2014-03-12 14:10:28
|
Hello, I am trying to load a CFFI library from the current directory. This is what I am trying to do: (asdf:oos 'asdf:load-op :cffi) (defpackage :cffi-user (:use :common-lisp :cffi)) (in-package :cffi-user) (define-foreign-library libfrontend (:unix (:or "libfrontend.so")) (t (:default "libfrontend"))) (let ((*foreign-library-directories* '(#p"."))) (use-foreign-library libfrontend)) But I keep getting the error Unable to load any of the alternatives: ("libfrontend.so") I tried to use an absolute path instead of the ".", but that did not help either. This is sbcl-1.1.16 on opensuse-12.3. With sbcl-1.1.16 on ubuntu-12.4, it seems to work fine. Any ideas? -- Josef Wolf jw...@ra... |
From: Josef W. <jw...@ra...> - 2014-03-14 12:30:21
|
On Wed, Mar 12, 2014 at 03:02:22PM +0100, Josef Wolf wrote: > Hello, > > I am trying to load a CFFI library from the current directory. This is what I > am trying to do: > > (asdf:oos 'asdf:load-op :cffi) > > (defpackage :cffi-user > (:use :common-lisp :cffi)) > > (in-package :cffi-user) > > (define-foreign-library libfrontend > (:unix (:or "libfrontend.so")) > (t (:default "libfrontend"))) > > (let ((*foreign-library-directories* '(#p"."))) > (use-foreign-library libfrontend)) > > But I keep getting the error > > Unable to load any of the alternatives: > ("libfrontend.so") > > I tried to use an absolute path instead of the ".", but that did not help > either. > > This is sbcl-1.1.16 on opensuse-12.3. > With sbcl-1.1.16 on ubuntu-12.4, it seems to work fine. The last conclusion is actually wrong: it doesn't have anything to do with suse/ubuntu. On both, suse _and_ ubuntu, it sometimes works and sometimes not. Any ideas how to track this down? -- Josef Wolf jw...@ra... |
From: Faré <fa...@gm...> - 2014-03-14 14:48:25
|
On Fri, Mar 14, 2014 at 8:26 AM, Josef Wolf <jw...@ra...> wrote: >> (asdf:oos 'asdf:load-op :cffi) >> More colloquial: (asdf:load-system :cffi) >> (define-foreign-library libfrontend >> (:unix (:or "libfrontend.so")) >> (t (:default "libfrontend"))) >> >> (let ((*foreign-library-directories* '(#p"."))) >> (use-foreign-library libfrontend)) >> #p"." is almost guaranteed to lose. Use an absolute pathname. (uiop:getcwd), *load-pathname*, *compile-file-pathname*, (asdf:system-relative-pathname :foo "lib/"), (uiop:subpathname *install-path* "lib/") or something will help you. In very recent versions of ASDF and cl-launch, (parse-native-namestring (argv0)) might help. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Judge historical figures by their relative contribution to then-prevailing opinions, not by failings they shared with their contemporaries. |
From: Josef W. <jw...@ra...> - 2014-03-14 17:40:22
|
On Fri, Mar 14, 2014 at 10:47:48AM -0400, Faré wrote: > On Fri, Mar 14, 2014 at 8:26 AM, Josef Wolf <jw...@ra...> wrote: > >> (asdf:oos 'asdf:load-op :cffi) > More colloquial: > (asdf:load-system :cffi) OK. But that did not help, either. > >> (define-foreign-library libfrontend > >> (:unix (:or "libfrontend.so")) > >> (t (:default "libfrontend"))) > >> > >> (let ((*foreign-library-directories* '(#p"."))) > >> (use-foreign-library libfrontend)) > >> > #p"." is almost guaranteed to lose. > Use an absolute pathname. I tried that also, but it did not help. Sometimes it works and sometimes not. I've tried both, relative and absolute pathnames. -- Josef Wolf jw...@ra... |
From: Faré <fa...@gm...> - 2014-03-14 20:32:02
|
>> >> (define-foreign-library libfrontend >> >> (:unix (:or "libfrontend.so")) >> >> (t (:default "libfrontend"))) >> >> >> >> (let ((*foreign-library-directories* '(#p"."))) >> >> (use-foreign-library libfrontend)) >> >> >> #p"." is almost guaranteed to lose. >> Use an absolute pathname. > > I tried that also, but it did not help. Sometimes it works and sometimes > not. I've tried both, relative and absolute pathnames. > 1- Ask on the CFFI mailing-list. 2- check your LD_LIBRARY_PATH and such. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To a woman, a man is capital. To a man, a woman is consumer goods. Hence the difference in attitude. |
From: Tito L. <tit...@gm...> - 2014-03-15 12:34:47
|
> But I keep getting the error > > Unable to load any of the alternatives: > ("libfrontend.so") Perhaps you get some info from dlerror if you replace (:unix (:or "libfrontend.so")) with (:unix "libfrontend.so") Example: libfrontend.so depends on another lib in "." $ file $PWD /tmp: symbolic link to `/dev/shm/' $ sbcl --load posted-code.lisp [...] Unable to load foreign library (LIBFRONTEND). Error opening shared object "/dev/shm/libfrontend.so": libeccio.so: cannot open shared object file: No such file or directory. [...] If it is your case, the example is like: handle = dlopen("/path/to/libfrontend.so", RTLD_GLOBAL | RTLD_NOW); CFFI:*FOREIGN-LIBRARY-DIRECTORIES* doesn't fix the dependencies of the library. $ ldd libfrontend.so | grep libeccio libeccio.so => not found A possible solution is to recompile libfrontend.so with `-R $PWD' or `-rpath $PWD' for ld when using ELF or $ LD_LIBRARY_PATH="$LD_LIBRARY_PATH:." sbcl --load posted-code.lisp Tito Latini |
From: Josef W. <jw...@ra...> - 2014-03-20 09:10:21
|
On Sat, Mar 15, 2014 at 01:29:27PM +0100, Tito Latini wrote: > > But I keep getting the error > > Unable to load any of the alternatives: > > ("libfrontend.so") > > Perhaps you get some info from dlerror if you replace > (:unix (:or "libfrontend.so")) > with > (:unix "libfrontend.so") > Example: libfrontend.so depends on another lib in "." Hmm, The error from dlerror would be expected. After all, it is (normally) not supposed to search in the current directory. This is the reason for setting CFFI:*FOREIGN-LIBRARY-DIRECTORIES*. libfrontend.so is created by myself and is located in the current directory. > $ file $PWD > /tmp: symbolic link to `/dev/shm/' > > $ sbcl --load posted-code.lisp > [...] > Unable to load foreign library (LIBFRONTEND). > Error opening shared object "/dev/shm/libfrontend.so": > libeccio.so: cannot open shared object file: No such file or directory. > [...] I don't understand. My libfrontend.so doesn't need anything except libc > If it is your case, the example is like: > handle = dlopen("/path/to/libfrontend.so", RTLD_GLOBAL | RTLD_NOW); > CFFI:*FOREIGN-LIBRARY-DIRECTORIES* doesn't fix the dependencies of the library. Isn't CFFI responsible to deal with the details of loading the library? > $ ldd libfrontend.so | grep libeccio > libeccio.so => not found jw@tm8371-u:/rep/git/public/jw/dvb$ ldd libfrontend.so linux-gate.so.1 => (0xb7767000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb69d3000) /lib/ld-linux.so.2 (0xb7768000) jw@tm8371-u:/rep/git/public/jw/dvb$ Currently, I can't test your suggestions, since the problem disappeared. Unfortunately, I have no idea what I have done to fix it. -- Josef Wolf jw...@ra... |
From: Tito L. <tit...@gm...> - 2014-03-21 07:42:28
|
On Thu, Mar 20, 2014 at 10:00:23AM +0100, Josef Wolf wrote: > On Sat, Mar 15, 2014 at 01:29:27PM +0100, Tito Latini wrote: > > > But I keep getting the error > > > Unable to load any of the alternatives: > > > ("libfrontend.so") > > > > Perhaps you get some info from dlerror if you replace > > (:unix (:or "libfrontend.so")) > > with > > (:unix "libfrontend.so") > > Example: libfrontend.so depends on another lib in "." > > Hmm, The error from dlerror would be expected. After all, it is (normally) not > supposed to search in the current directory. > > This is the reason for setting CFFI:*FOREIGN-LIBRARY-DIRECTORIES*. > libfrontend.so is created by myself and is located in the current directory. posted-code.lisp used in the example is your posted code; the diff is - (:unix (:or "libfrontend.so")) + (:unix "libfrontend.so") > > $ file $PWD > > /tmp: symbolic link to `/dev/shm/' > > > > $ sbcl --load posted-code.lisp > > [...] > > Unable to load foreign library (LIBFRONTEND). > > Error opening shared object "/dev/shm/libfrontend.so": > > libeccio.so: cannot open shared object file: No such file or directory. > > [...] > > I don't understand. My libfrontend.so doesn't need anything except libc I don't have your lib. libfrontend.so is a dummy library compiled for the example "lib depends on another lib in ." > > If it is your case, the example is like: > > handle = dlopen("/path/to/libfrontend.so", RTLD_GLOBAL | RTLD_NOW); > > CFFI:*FOREIGN-LIBRARY-DIRECTORIES* doesn't fix the dependencies of the library. > > Isn't CFFI responsible to deal with the details of loading the library? No, it resolves only the path of the library (not the dependencies). > > $ ldd libfrontend.so | grep libeccio > > libeccio.so => not found > > jw@tm8371-u:/rep/git/public/jw/dvb$ ldd libfrontend.so > linux-gate.so.1 => (0xb7767000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb69d3000) > /lib/ld-linux.so.2 (0xb7768000) > jw@tm8371-u:/rep/git/public/jw/dvb$ > > > Currently, I can't test your suggestions, since the problem > disappeared. Unfortunately, I have no idea what I have done to fix it. YAFIYGI |