I am trying to install the GNU Scientific Library for Lisp (GSLL).
I saw there are answers to a similar question already, but I didn't find the connection to what is happening in my case.
Could anyone help to move on from here?
CL-USER> (lisp-implementation-type)
"SBCL"
CL-USER> (lisp-implementation-version)
"1.2.4.debian"
CL-USER> (ql:quickload "gsll")
; cc -m64 -I/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/ -o /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix.c
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
To load "gsll":
Load 8 ASDF systems:
alexandria antik asdf-system-connections cffi-grovel
cffi-libffi metabang-bind osicat trivial-garbage
Install 1 Quicklisp gsll
release:
; Loading "gsll"
; cc -m64 -I/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/ -o /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix /lrde/home/alandi/.cache/common-lisp/sbcl-1.2.4.debian-linux-x64/lrde/home/alandi/quicklisp/dists/quicklisp/software/cffi_0.14.0/libffi/libffi-unix.c
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
; Evaluation aborted on Component "gsll" not found.
I am on OS X, but maybe this helps you anyway. I could load the lib by (ql:quickload "gsll") but I had to make an adjustment:
The path to GSLs dynamic libraries is found by a shell call gsl-config --prefix.
For me this call returns /usr/local/Cellar/gsl/1.16 but my dynlibs are located in /usr/local/Cellar/gsl/1.16/lib. So I just had to make some adjustments to the pathnames in the file ~/quicklisp/dists/quicklisp/software/gsll-20140211-git/init/init.lisp.
Seach for (cffi:define-foreign-library libgslcblas ...) and (cffi:define-foreign-library libgsl ...) and adjust your paths there.
Maybe that helps.
Related
I'm trying to run an executable with an Hunchentoot server and I'm getting (after an unusual high CPU usage):
<INFO> [17:55:14] weblocks/server server.lisp (start) -
Starting weblocks WEBLOCKS/SERVER::PORT: 40001
WEBLOCKS/SERVER::SERVER-TYPE: :HUNCHENTOOT DEBUG: T
debugger invoked on a SB-INT:EXTENSION-FAILURE in thread
#<THREAD "main thread" RUNNING {1008C1EA13}>:
Don't know how to REQUIRE sb-cltl2.
Do you have any idea what's going on ? It works correctly on Slime where I use the start function.
(sbcl manual: http://www.sbcl.org/manual/#Customization-Hooks-for-Users)
In the main entry point, I try to capture the running thread so that I keep the server running on the foreground (my notes). This pattern worked with another clack-based web framework.
(defun start ()
(weblocks/debug:on)
(weblocks/server:start :port *port*))
(defun main ()
(defvar *port* (find-port:find-port))
(start)
(handler-case (bt:join-thread (find-if (lambda (th)
(search "hunchentoot" (bt:thread-name th)))
(bt:all-threads)))
(#+sbcl sb-sys:interactive-interrupt
#+ccl ccl:interrupt-signal-condition
#+clisp system::simple-interrupt-condition
#+ecl ext:interactive-interrupt
#+allegro excl:interrupt-signal
() (progn
(format *error-output* "Aborting.~&")
(uiop:quit 1))
;; for others, unhandled errors (we might want to do the same).
(error (c) (format t "Woops, an unknown error occured:~&~a~&" c)))))
Or any indication of what could be the cause ?
Thanks again.
(I'm using 40ants' weblocks:reblocks branch)
SBCL Debian 1.2.4
edit I tried
export SBCL_HOME=/usr/local/lib/sbcl/
I build with
build:
$(LISP) --quit \
--eval '(ql:quickload "foo")' \
--eval '(require :sb-cltl2)' \
--eval '(asdf:make :foo)'
=>
fatal error encountered in SBCL pid 25248(tid 140737353910016):
can't load .core for different runtime, sorry
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>
The following environment failed:
export SBCL_HOME=/usr/local/lib/sbcl/
The error message tells us the following:
can't load .core for different runtime, sorry
Apparently the SBCL you ran used the given SBCL_HOME to find its core file, but failed due to the core being generated by different version SBCL.
A quick look at SBCL's source (starting from require) shows that the underlying function #'SB-INT:SBCL-HOMEDIR-PATHNAME is called to determine the installation path.
It looks like the one installed from the Debian package was installed in /usr/lib/sbcl/. The core file was easily found when starting Slime. You also had another version of SBCL in ~/.roswell/, but I guess you also ran ros install which installed it under /usr/local/lib/sbcl (/usr/local/ is for software that is not managed by the system).
Starting the roswell one when setting SBCL_HOME to the directory of the Debian one provoked the error about the incompatible core file (I guess).
What remains suprising is that (SB-INT:SBCL-HOMEDIR-PATHNAME) returns nil when starting your main function.
I'm trying to build an executable with ECL. I looked at the doc and this other SO question, where we learn that with ECL v <= 16.1.3 we must add a
(require 'adsf)
Then I push my project to the asdf registry:
(pushnew "~/projects/my-project/" asdf:*central-registry* :test #'equal)
I load it:
(load "my-project.asd")
My program obviously has Quicklisp dependencies.
I copied the initialization of Quicklisp from my .sbclrc to ~/.eclrc:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
(when (probe-file quicklisp-init)
(load quicklisp-init)))
So than I can Quickload my project: (this step does not appear in the doc but this allows to find the project dependencies)
(ql:quickload "my-project")
I also
(use-package :my-project)
but now, as I want to build the executable with
(asdf:make-build :my-project
:type :program
:move-here #P"./"
:epilogue-code '(progn (my-project:main)
(si:exit)))
I get the error
Cannot find the external symbol MAKE-BUILD in #<"ASDF/INTERFACE" package>.
Can someone help ? Thanks !
ECL 16.1.3
ps: and it seems that, in the REPL, to enter a restart nb has no effect.
My makefile:
ecl-build:
~/.roswell/impls/x86-64/linux/ecl/16.1.3/bin/ecl \
--eval "(require 'asdf)" \
--eval '(format t "--- ASDF version: ~a~&" (asdf:asdf-version))' \
--eval "(pushnew \"~/projets/cl-torrents/\" asdf:*central-registry* :test 'equal)" \
--eval '(load "cl-torrents.asd")' \
--eval '(asdf:make-build :cl-torrents :type :program :move-here #P"./" :epilogue-code "(progn (torrents "matrix") (si:exit))")'
Result:
;;; Loading "/home/vince/quicklisp/setup.lisp"
;;; Loading #P"/home/vince/.roswell/impls/x86-64/linux/ecl/16.1.3/lib/ecl-16.1.3/asdf.fas"
--- ASDF version: 3.2.1
An error occurred during initialization:
Cannot find the external symbol MAKE-BUILD in #<"ASDF/INTERFACE" package>..
Makefile:22: recipe for target 'ecl-build' failed
make: *** [ecl-build] Error 1
edit 27, oct - progress
The simplest path now seems to unsure to use ASDF bundled into ECL, which will have the make-build command.
I had a newer ASDF version because of my Quicklisp's initialization code into ~/.eclrc. I removed it and now I have ASDF v3.1.8.2, which is ok. But now, ECL doesn't know any dependencies:
Component :DEXADOR not found, required by #.
Indeed, because there is no Quicklisp any more.
ECL doc says to include all libraries path into asdf:*central-registry*. By chance, Quicklisp installed all libraries into ~/quicklisp/dists/quicklisp/software/.
First, I wonder how this will work in a CI pipeline where Quicklisp has not run before…
Then I see that adding only this directory is not enough, Dexador's dependencies will in turn not be found, I had to add dexador's directory precisely:
--eval "(pushnew \"~/quicklisp/dists/quicklisp/software/dexador-20170830-git/\" asdf:*central-registry* :test 'equal)" \
So do I really have to write code to include every directory here ?
How to make this work when Quicklisp has not run once before ?
update: With Ecl installed with Roswell: requireing asdf before everything in my .eclrc gives the version 3.1.8.2, after Quicklisp initialization 3.2.1 and make-build symbol unknown.
With Debian's Ecl: first v2.33.10 and then v3.2.1 likewise.
Looks like a dead end.
update november: I waited for the release of ASDF 3.3.0 to manually update. It was buggy. Message on the mailing list: waiting for 3.3.1: buggy again.
Went with the lisp-devel Docker image, shipping ECL 16.1.3. (I don't want to compile ECL myself on each and every VPS). I could build an executable (52Mo in weight), but got a runtime error:
Condition of type: SIMPLE-ERROR
Package ((UIOP/STREAM . #)) referenced in > compiled file
NIL
but has not been created
It seems a problem with comtibility with ASDF and ECL this is solved in last commit take a look here,
Add back make-build on ECL
This provides for backward compatibility with ECL, whose current
maintainer Daniel K. has decided to keep supporting the make-build
interface and has forked ASDF for that.
you can install/use the last ASDF from this repo
You may use either bundled ASDF (which is a frozen 3.1.7 version with some fixes backported) – then you load ASDF with (require asdf), or you may use upstream 3.3 version.
If you are interested in using upstream ASDF, download asdf.lisp file and call:
(load (compile-file "/path/to/asdf.lisp")) instead of (require 'asdf).
I Went with the lisp-devel Docker image, shipping ECL 16.1.3. (I don't want to compile ECL myself on each and every VPS). I could build an executable (52Mo in weight VS 78Mo with SBCL), so I was able to deliver it with Gitlab CI.
For reference, to launch Docker and mount your sources:
service docker start
docker run --rm -it -v /home/you/projets/project:/usr/local/share/common-lisp/source daewok/lisp-devel:latest bash
Unfortunately I got a runtime error:
Condition of type: SIMPLE-ERROR
Package ((UIOP/STREAM . #)) referenced in > compiled file
NIL
but has not been created
It also seems I had to ql:quickload :closer-mop manually before loading my app.
I won't investigate this.
I have a weird mix of errors.
I was using CL21, I was in my package, and I wanted to install lparallel. Not possible:
(ql:quickload :lparallel)
To load "lparallel":
Load 1 ASDF system:
lparallel
; Loading "lparallel"
;
; caught ERROR:
; DYNAMIC-EXTENT on a weird thing: (CL21.CORE.FUNCTION:FUNCTION #:BODY-FN1)
;
; compilation unit aborted
; caught 2 fatal ERROR conditions
; caught 1 ERROR condition
; Evaluation aborted on #<UIOP/LISP-BUILD:COMPILE-FILE-ERROR {1008956C13}>.
I can reproduce it in a new session but it's a bit weird: if I quickload lparallel in cl-user, it complains on not finding the symbol CL21.CORE.FUNCTION, even if I didn't do nothing with CL21 yet:
The name "CL21.CORE.FUNCTION" does not designate any package.
So I ql:quickload CL21 and then on retrying to load lparallel. I get the first error.
But, I tried in Portacle for a fresh image and… I couldn't reproduce this.
Any idea ? Is that an issue with cl21, lparallel, quicklisp or asdf??
cl21 seems to replace the standard reader macro #' with its own version that isn't compatible with lparallel. When you tried to load lparallel in a fresh image, ASDF will load it from the .fasl-files that were compiled with cl21 loaded, so you must either delete those files or force recompilation with
(asdf:operate 'asdf:load-op :lparallel :force t)
Loading cl21 after lparallel is compiled with the standard language shouldn't cause the same problem.
Some days ago I updated SBCL to 1.2.1 and I thought it couldn't hurt to update the quick lisp dist/client as well.
WRONG!
After firing up slime in Emacs, I got this error:
; caught ERROR:
; READ error during COMPILE-FILE:
;
; Symbol "CODE-TRACE-TABLE-OFFSET-SLOT" not found in the SB-VM package.
;
; Line: 1507, Column: 70, File-Position: 60197
;
; Stream: #<SB-SYS:FD-STREAM
; for "file /Users/fyi/quicklisp/dists/quicklisp/software/slime-2.7/swank-sbcl.lisp"
; {1008B07E43}>
;
; compilation unit aborted
; caught 1 fatal ERROR condition
; caught 1 ERROR condition
; printed 1 note
;;
;; Error while compiling /Users/fyi/quicklisp/dists/quicklisp/software/slime-2.7/swank-sbcl.lisp:
;; COMPILE-FILE returned NIL.
;; Aborting.
If you're using the quicklisp-slime-helper, so as I, the path to slime comes form the ~/quicklisp/dists/quicklisp/installed/systems/swank.txt file. Slime 2.8 should fix that error, but there is no quicklisp distribution that contains slime 2.8.
Coming down to my actual question. Is there a way to specify a library location outside of a quicklisp distribution? Or will I have to wait unit the next distribution has been made available and is there a guaranty a library will be updated in the next distribution?
I am sure I'm missing something, but the whole distribution stuff seems to me more of a hindrance than a help.
The next Quicklisp dist update is coming July 12 or 13. It will include a new SLIME that is compatible with SBCL 1.2.1. In the meantime, the easiest fix is to install SBCL 1.2.0.
Another option is to comment out the quicklisp-slime-helper lines in ~/.emacs and install slime according to its own procedure.
I've been installing lispbuilder-sdl family with quicklisp and encountered error in sdl-gfx:
CL-USER> (ql:quickload "lispbuilder-sdl-gfx")
To load "lispbuilder-sdl-gfx":
Load 1 ASDF system:
lispbuilder-sdl-gfx
; Loading "lispbuilder-sdl-gfx"
...........;
; compilation unit aborted
; caught 1 fatal ERROR condition
Unable to load any of the alternatives:
("libSDL_gfx.dylib" (:FRAMEWORK "SDL_gfx"))
[Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]
I use slime+emacs+SBCL under macosx 10.6. I've installed SDL.framework from this link:
http://thirdcog.eu/apps/frameworks#glew
a file called sdl_with_friends.zip and put things under /Library/Frameworks. However it still complains about cannot find framework.
Any idea on this?
The easiest way to install lispbuilder-sdl on Mac OSX is to fire up SBCL and use Quicklisp:
(ql:quickload "lispbuilder-sdl")
It will probably fail, but you can then compile the OS-X specific helper library located in "~quicklisp/dists/quicklisp/software/lispbuilder-20110619-svn/lispbuilder-sdl/cocoahelper"; just cd to this directory and type "make"
To verify that worked, try this:
(ql:quickload "lispbuilder-sdl-examples")
(lispbuilder-sdl-examples:bezier)
Another common gotcha is when you are using Emacs / SLIME. The cocoa bits must run on the primary thread, so you have to invoke things like this:
#+darwin #+sb-thread
(let ((thread (first (last (sb-thread:list-all-threads)))))
(sb-thread:interrupt-thread thread #'(lambda () (ql:quickload "lispbuilder-sdl-examples")))
(sb-thread:interrupt-thread thread #'(lambda () (lispbuilder-sdl-examples:bezier))))
The error is complaining that it can't load the dynamic library for SDL. I'm sorry - I don't know much about the directory layout on macs (which appears to be where you're working), so I can't exactly tell you how to fix this. But somewhere you should have installed a file called libSDL_gfx.dylib (probably this extension) and the error message means that CFFI is failing to find it.
using homebrew you can brew install sdl_gfx