[Gsll-devel] extra info in the example section

[Liam Healy]

On Wed, Apr 28, 2010 at 4:02 AM, N J <raphexion at gmail.com> wrote:
> On Wed, Apr 28, 2010 at 3:22 AM, Liam Healy <lhealy at common-lisp.net> wrote:
>> I'm not sure what you're looking for here, but I've never
>> had  "GSL libraries not loadable" (not sure what you mean
>> here; not found in the path?).  Doesn't the form
>> (cffi:use-foreign-library libgsl)
>> at the end of init/init.lisp fail with some kind of reasonable
>> error message if it doesn't find the libraries?   What else
>> is needed?
>
> I am a beginner of both lisp and lisp packages and I remember that I
> got a very puzzled when I just started using gsll. After testing
> different combination of packages (stable and unstable) I finally
> managed to installed all the packages successfully (gentoo). Then I
> tried the
>
>    (asdf:operate 'asdf:load-op :gsll)
>
> in sbcl. And I got tons of messages and error messages:
>
>  *put last in email for readability

Generally speaking in any programming language, you should look
at the *first* error message and try to figure out what caused it.  Granted,
that's not always easy to find, but in your case it is actually coming from
gcc,

> error: ffi.h: No such file or directory

which indicates that it can't find the path to the libffi header file, used
by FSBV.  This is a common problem unfortunately.  I threw up my
hands at trying to solve this in general.  If anyone has any ideas,
I'd like to know it.

As for stopping the run-on error messages so that it's easier
to find the first one, it would be nice, but
again, I don't know how to do that.  Perhaps the CFFI mailing
list would help.

>
> And because there were so much information (compile messages and error
> messages) I had no clue how to continue. Either I hadn't really
> installed the packages correctly (gentoo) or I had a problem with
> gsll. Then, when I finally got it to compile (with the help from here
> by the way, thanks) it was not really obvious for me that everything
> was successful.

That does take some getting used to.  Unfortunately that's more
a product of the compiler and not really anything GSLL can do.
Some compilers and environments are better than others.

>
> So, maybe it is redundant for most people but it would be very helpful
> to have some sort of checklist / getting started, on the web page, to
> be able to see what is working and not. Especially as there are 4-5
> packages that needs to be installed, and people are using different
> systems (Ubuntu, Debian, Gentoo or just git) and will end up with
> different versions.
>
> Or maybe, a summery at the very end of the (asdf:operate 'asdf:load-op
> :gsll),  saying that everything went as expected or which part that
> went wrong.

I'm not sure what you mean here.  A checklist of what?
"Getting started" in general is hard because of the tremendous
variety of implementations and operating systems, where
output looks very different.  You can see on the web page
I provided installation
instructions, and I'm going to remove most of it because it
is incomplete and too hard to make complete.  It is also
unwise to rely on features that may change or be unsupported
because then it's a headache to maintain.

I sympathize with the difficulty of interpreting output from
an unfamiliar system, and distinguishing success from
failure, but I don't see how GSLL can overcome that.
I can't think of any other CL system that does something
like think; if someone knows of something, we could copy it and
adapt it to GSLL.

Liam

>
> // NIK
>
> *
> ; loading system definition from /usr/share/common-lisp/systems/c-array.asd
> ; into #<PACKAGE "ASDF0">
> ; registering #<SYSTEM C-ARRAY {10026C51D1}> as C-ARRAY
> ; compiling file "/usr/share/common-lisp/source/fsbv/init.lisp"
> (written 01 MAR 2010 11:39:35 PM):
> ; compiling (IN-PACKAGE :COMMON-LISP-USER)
> ; compiling (DEFPACKAGE :FOREIGN-STRUCTURES-BY-VALUE ...)
> ; compiling (CFFI:LOAD-FOREIGN-LIBRARY "libffi.so")
> ; compiling (PUSHNEW :FSBV ...)
>
> ; /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/init.fasl
> written
> ; compilation finished in 0:00:00
> ; cc -m64 -fPIC -o
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c
>
> debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread"
> RUNNING {10023F6A01}>:
>  External process exited with code 1.
> Command was: "cc" "-m64" "-fPIC" "-o"
> "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix"
> "/home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c"
> Output was:
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:7:17:
> error: ffi.h: No such file or directory
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:
> In function ‘main’:
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40:
> error: ‘FFI_OK’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40:
> error: (Each undeclared identifier is reported only once
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:40:
> error: for each function it appears in.)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:45:
> error: ‘FFI_BAD_TYPEDEF’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:50:
> error: ‘FFI_BAD_ABI’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:61:
> error: ‘FFI_DEFAULT_ABI’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:66:
> error: ‘FFI_SYSV’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:71:
> error: ‘FFI_UNIX64’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:79:
> error: ‘ffi_abi’ undeclared (first use in this function)
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126:
> error: invalid application of ‘sizeof’ to incomplete type ‘struct
> _ffi_type’
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:126:
> warning: format ‘%i’ expects type ‘int’, but argument 3 has type ‘long
> unsigned int’
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:131:
> error: dereferencing pointer to incomplete type
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:136:
> error: dereferencing pointer to incomplete type
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:141:
> error: dereferencing pointer to incomplete type
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:146:
> error: dereferencing pointer to incomplete type
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:
> In function ‘print_double_for_lisp’:
> /home/rpx/.fasls/sbcl-1.0.19-gentoo-linux-x86-64/usr/share/common-lisp/source/fsbv/libffi-unix.c:397:
> warning: incompatible implicit declaration of built-in function
> ‘memset’
>
>> Liam
>>
>> On Tue, Apr 27, 2010 at 8:56 AM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
>> ...
>>>
>>> Good idea.  Here is another one that would be useful even for the
>>> pros.  A gsll-probe, that would probe the system to make sure that
>>> gsll is loadable.  The main thing that comes to mind, and that can
>>> look scary to a newbie is if the gsl libraries are not loadable.
>>>
>>> Along those lines, I was wandering if the gsll setup would be easier
>>> if the user were required to set-up a feature *gsll-user* (or some
>>> other such name.  This symbol would have in its plist the gsl library
>>> location.
>>>
>>> Mirko
>>
>