[STUMP] Building with CLISP
Aidan Gauland
2.49. I tried building it on my Debian squeeze (stable) system (with
the CLISP package from wheezy (testing), because 2.49 is not in
squeeze), and got an error. Here is my shell session from trying to
build.
Regards,
Aidan Gauland
$ git clone --depth 1 git://git.savannah.nongnu.org/stumpwm.git
Cloning into stumpwm...
remote: Counting objects: 401, done.
remote: Compressing objects: 100% (270/270), done.
remote: Total 401 (delta 270), reused 205 (delta 127)
Receiving objects: 100% (401/401), 444.36 KiB | 94 KiB/s, done.
Resolving deltas: 100% (270/270), done.
$ cd stumpwm/
$ autoconf
$ ./configure --with-lisp=clisp --with-ppcre=/usr/share/common-lisp/source/cl-ppcre
checking for sbcl... /usr/bin/sbcl
checking for clisp... /usr/bin/clisp
checking for ccl... no
checking for ecl... no
configure: Using clisp at /usr/bin/clisp
checking for makeinfo... yes
checking for xdpyinfo... yes
checking for /usr/share/common-lisp/source/cl-ppcre/cl-ppcre.asd... yes
configure: creating ./config.status
config.status: creating Makefile
configure: creating ./config.status
config.status: creating Makefile
config.status: creating make-image.lisp
configure: creating ./config.status
config.status: creating Makefile
config.status: creating make-image.lisp
config.status: creating version.lisp
$ make
/usr/bin/clisp -K full -on-error exit ./make-image.lisp
/usr/bin/clisp: /usr/lib/clisp-2.49/full/lisp.run: No such file or directory
make: *** [stumpwm] Error 1
$
_______________________________________________
Stumpwm-devel mailing list
Stumpw...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Aidan Gauland
> On 2011-07-02 09:20:49 +0800, Aidan Gauland wrote:
>> $ make
>> /usr/bin/clisp -K full -on-error exit ./make-image.lisp
>> /usr/bin/clisp: /usr/lib/clisp-2.49/full/lisp.run: No such file or directory
>
> I have met this problem. Check if lisp.run is there. In my system, it's
> under directory
>
> /usr/lib/clisp-2.49/base
>
> . You can symlink it to /usr/lib/clisp-2.49/full.
On my system, there is no directory (or file) /usr/lib/clisp-2.49/full,
so I had to create it. I then symlinked
/usr/lib/clisp-2.49/base/lisp.run to /usr/lib/clisp-2.49/full/ and ran
make. Different error and still no joy.
$ make
/usr/bin/clisp -K full -on-error exit ./make-image.lisp
/usr/lib/clisp-2.49/full/lisp.run: operating system error during load of initialization file `/usr/lib/clisp-2.49/full/lispinit.mem'
[/build/clisp-QkfhfL/clisp-2.49/src/spvw_memfile.d:982] errno = ENOENT: No such file or directory.
make: *** [stumpwm] Error 1
$
--Aidan
Wang Lei
On 2011-07-02 09:20:49 +0800, Aidan Gauland wrote:
I have met this problem. Check if lisp.run is there. In my system, it's
under directory
/usr/lib/clisp-2.49/base
. You can symlink it to /usr/lib/clisp-2.49/full.
> make: *** [stumpwm] Error 1
> $
>
>
> _______________________________________________
> Stumpwm-devel mailing list
> Stumpw...@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
--
Regards
Lei
Dirk Sondermann
> I think StumpWM's build system needs to be updated to work with CLISP
> 2.49. I tried building it on my Debian squeeze (stable) system (with
> the CLISP package from wheezy (testing), because 2.49 is not in
> squeeze), and got an error. Here is my shell session from trying to
> build.
> $ make
> /usr/bin/clisp -K full -on-error exit ./make-image.lisp
> /usr/bin/clisp: /usr/lib/clisp-2.49/full/lisp.run: No such file or directory
> make: *** [stumpwm] Error 1
Debian builds clisp-2.49 with dynamic modules support, which has
become the default in that version. clx and other additional modules
are provided by separate packages now and there is no longer a "full"
linking set which contains all additional modules. But you can easily
create such a linking set by installing the desired clisp-module-*
packages and using clisp-link.
stumpwm needs the module new-clx (provided by clisp-module-clx), so
an appropriate "full" linking set may be created by
clisp-link add /usr/lib/clisp-2.49/base \
/usr/lib/clisp-2.49/full \
/usr/lib/clisp-2.49/clx/new-clx
(Disclaimer: Since I'm not using Debian I did not test this procedure
with Debian's clisp. But it works with a clisp built from source.)
--
Dirk
Dirk Sondermann
> But you can easily create such a linking set by installing the
> desired clisp-module-* packages and using clisp-link.
As a more convenient alternative, you may apply the patch posted by
Ben Spencer on March 22 on this list. Since make-image.lisp.in has
changed in the meantime, I've attached an updated version of that
patch.
--
Dirk
Ben Spencer
> As a more convenient alternative, you may apply the patch posted by
> Ben Spencer on March 22 on this list. Since make-image.lisp.in has
> changed in the meantime, I've attached an updated version of that
> patch.
Unfortunately this makes it build but the resulting binary doesn't work:
ben@arctor:~/src/stumpwm$ ./stumpwm
module 'syscalls' requires package OS.
I guess it needs to be told to load the required modules on startup.
Any ideas?
Ben
Dirk Sondermann
> On Mon, Jul 04, 2011 at 12:10:19AM +0200, Dirk Sondermann wrote:
>> As a more convenient alternative, you may apply the patch posted by
>> Ben Spencer on March 22 on this list. Since make-image.lisp.in has
>> changed in the meantime, I've attached an updated version of that
>> patch.
>
> Unfortunately this makes it build but the resulting binary doesn't work:
>
> ben@arctor:~/src/stumpwm$ ./stumpwm
> module 'syscalls' requires package OS.
>
> I guess it needs to be told to load the required modules on startup.
> Any ideas?
No. It seems that saved images fail to start as soon as dynamic modules
are involved (even in the simplest case):
$ clisp -x '(require "clx")' -x '(ext:saveinitmem "test" :executable t)'
$ ./test
module 'syscalls' requires package OS.
This problem has been solved in the clisp version from the Mercurial
repository:
$ ./test
...
Welcome to GNU CLISP 2.49+
...
[1]> (xlib:window-p nil)
NIL
So we may have to wait for version 2.50 to get released.
--
Dirk
Dirk Sondermann
>> As a more convenient alternative, you may apply the patch posted by
>> Ben Spencer on March 22 on this list. Since make-image.lisp.in has
>> changed in the meantime, I've attached an updated version of that
>> patch.
>
> Unfortunately this makes it build but the resulting binary doesn't work:
>
> ben@arctor:~/src/stumpwm$ ./stumpwm
> module 'syscalls' requires package OS.
I've combined your patch with the creation of a temporary linking
set using clisp-link. The resulting binary now actually works.
For building stumpwm on Debian wheezy with this patch, in addition
to the packages clisp and clisp-module-clx also clisp-dev has to
be installed.
--
Dirk
Aidan Gauland
I tried that patch and was not even able to build Stump.
$ git clone --depth 1 git://git.savannah.nongnu.org/stumpwm.git
Cloning into stumpwm...
remote: Counting objects: 401, done.
remote: Compressing objects: 100% (270/270), done.
remote: Total 401 (delta 270), reused 205 (delta 127)
Receiving objects: 100% (401/401), 444.36 KiB | 110 KiB/s, done.
Resolving deltas: 100% (270/270), done.
$ cd stumpwm/
$ patch -p1 < /home/aidan/clisp-with-dynamic-modules.patch
patching file Makefile.in
patching file configure.ac
$ autoconf
$ ./configure --with-lisp=clisp --with-ppcre=/usr/share/common-lisp/source/cl-ppcre
checking for sbcl... /usr/bin/sbcl
checking for clisp... /usr/bin/clisp
checking for ccl... no
checking for ecl... no
configure: Using clisp at /usr/bin/clisp
checking for makeinfo... yes
checking for xdpyinfo... yes
checking for /usr/share/common-lisp/source/cl-ppcre/cl-ppcre.asd... yes
checking whether clisp is built with dynamic modules support... yes
configure: creating ./config.status
config.status: creating Makefile
configure: creating ./config.status
config.status: creating Makefile
config.status: creating make-image.lisp
configure: creating ./config.status
config.status: creating Makefile
config.status: creating make-image.lisp
config.status: creating version.lisp
$ make
MAKE=: clisp-link add "`clisp -b`/base" clisp-core "`clisp -b`/clx/new-clx"
/usr/bin/clisp-link: Cannot determine the dynamic module directory: *lib-directory* is not writable and *user-lib-directory* is not specified
make: *** [clisp-core] Error 1
I have the following clisp packages installed.
$ dpkg -l '*clisp*' | grep \^ii
ii clisp 1:2.49-7 GNU CLISP, a Common Lisp implementation
ii clisp-dev 1:2.49-7 GNU CLISP, a Common Lisp implementation (development files)
ii clisp-module-clx 1:2.49-7 clisp module that adds X11 bindings
I should probably restate that I am on Debian squeeze, but the clisp
packages are pulled in from wheezy.
Regards,
Aidan Gauland
Dirk Sondermann
...
> I tried that patch and was not even able to build Stump.
> $ make
> MAKE=: clisp-link add "`clisp -b`/base" clisp-core "`clisp -b`/clx/new-clx"
> /usr/bin/clisp-link: Cannot determine the dynamic module directory: *lib-directory* is not writable and *user-lib-directory* is not specified
> make: *** [clisp-core] Error 1
>
> I have the following clisp packages installed.
> $ dpkg -l '*clisp*' | grep \^ii
> ii clisp 1:2.49-7 GNU CLISP, a Common Lisp implementation
> ii clisp-dev 1:2.49-7 GNU CLISP, a Common Lisp implementation (development files)
> ii clisp-module-clx 1:2.49-7 clisp module that adds X11 bindings
>
> I should probably restate that I am on Debian squeeze, but the clisp
> packages are pulled in from wheezy.
>
> Regards,
> Aidan Gauland
This seems to be a permission problem which can be avoided
by preventing clisp-link from writing into the lib directory.
I hadn't noticed this problem before because in my test
installation the lib directory was writeable.
Could you please give the attached new version of the patch
a try?
--
Dirk
Aidan Gauland
> Could you please give the attached new version of the patch
> a try?
Now gcc spits out these errors (and the build fails). Am I missing some
header packages? And if so, shouldn't the configure script have noticed
that?
gcc: /usr/lib/libreadline.so: No such file or directory
gcc: /usr/lib/libavcall.so: No such file or directory
gcc: /usr/lib/libcallback.so: No such file or directory
--Aidan
Dirk Sondermann
> Dirk Sondermann <ds-st...@dyximaq.de> writes:
>> Could you please give the attached new version of the patch
>> a try?
>
> Now gcc spits out these errors (and the build fails). Am I missing some
> header packages? And if so, shouldn't the configure script have noticed
> that?
>
> gcc: /usr/lib/libreadline.so: No such file or directory
> gcc: /usr/lib/libavcall.so: No such file or directory
> gcc: /usr/lib/libcallback.so: No such file or directory
>
> --Aidan
It's difficult for the configure script to give an appropriate warning
because it doesn't know the dependencies of clisp-link in detail.
I don't see a better solution than installing the missing libraries which
gcc complains about and then trying again by running 'make clean' (this
step shouldn't be skipped) and 'make'.
libreadline.so is part of the package libreadline5-dev, libavcall.so and
libcallback.so are part of libffcall1-dev.
--
Dirk
Aidan Gauland
> Could you please give the attached new version of the patch
> a try?
OK, still fails, but actually starts to compile. I have attached the
output of make this time, as some of the lines are very long. Looks
much more cryptic (to me) than the previous errors.
--Aidan
Aidan Gauland
> OK, still fails, but actually starts to compile. I have attached the
> output of make this time, as some of the lines are very long. Looks
> much more cryptic (to me) than the previous errors.
Oh, geez... I just noticed that my post has no attachment. Sorry for
the screwup. Here it is *for real* this time. :P
Yours cluelessly,
Aidan
Dirk Sondermann
> On 07/19/11 20:22, Aidan Gauland wrote:
>> OK, still fails, but actually starts to compile. I have attached the
>> output of make this time, as some of the lines are very long. Looks
>> much more cryptic (to me) than the previous errors.
> /usr/bin/clisp -K /usr/local/src/stumpwm/clisp-core -on-error exit ./make-image.lisp
> ; loading system definition from stumpwm.asd into #<PACKAGE ASDF0>
> ; registering #<SYSTEM :STUMPWM #x0003347B8EA0> as STUMPWM
> *** - UNIX error 13 (EACCES): Permission denied
This error isn't related to the new clisp version or its dynamic
modules support. (It has occurred after a temporary linking set had
been successfully created by clisp-link.)
The problem is that ASDF tries to store compiled fasl files in the
same directories where it has found the lisp sources. Since you
don't have write permissions on those directories, compiling the first
lisp file in /usr/share/common-lisp/source/cl-ppcre leads to an error.
There are several ways to avoid this problem. You could, for example,
use debian's ASDF infrastructure instead of the asdf.lisp that is
included in stumpwm.
If you are only interested in building a stumpwm binary, you could,
as a kludge, keep ASDF from saving fasl files anywhere by inserting
(pushnew :broken-fasl-loader *features*)
as first line of make-image.lisp (or make-image.lisp.in if you want
to rerun configure).
--
Dirk
Aidan Gauland
> The problem is that ASDF tries to store compiled fasl files in the
> same directories where it has found the lisp sources. Since you
> don't have write permissions on those directories, compiling the first
> lisp file in /usr/share/common-lisp/source/cl-ppcre leads to an error.
> There are several ways to avoid this problem. You could, for example,
> use debian's ASDF infrastructure instead of the asdf.lisp that is
> included in stumpwm.
How do I tell the build system to use Debian's ASDF package instead of
the bundles version?
--Aidan
Aidan Gauland
> as a kludge, keep ASDF from saving fasl files anywhere by inserting
>
> (pushnew :broken-fasl-loader *features*)
>
> as first line of make-image.lisp (or make-image.lisp.in if you want
> to rerun configure).
(Sorry, this should've gone in my previous post.)
Your suggested "kludge" seems to make no difference. :(
--Aidan
Dirk Sondermann
> On 31/07/11 23:31, Dirk Sondermann wrote:
>> The problem is that ASDF tries to store compiled fasl files in the
>> same directories where it has found the lisp sources. Since you
>> don't have write permissions on those directories, compiling the first
>> lisp file in /usr/share/common-lisp/source/cl-ppcre leads to an error.
>> There are several ways to avoid this problem. You could, for example,
>> use debian's ASDF infrastructure instead of the asdf.lisp that is
>> included in stumpwm.
>
> How do I tell the build system to use Debian's ASDF package instead of
> the bundles version?
As I'm not a Debian user, I'm probably not the right person to answer
this question.
I suppose that the Common Lisp Controler is the recommended tool to be
used (http://pkg-common-lisp.alioth.debian.org/clid/clid.html), but for
our purposes it should suffice to replace the asdf.lisp file included in
stumpwm with a link to /usr/share/common-lisp/source/cl-asdf/asdf.lisp
(which is part of the package cl-asdf).
As long as no particular mapping rules have been defined, ASDF now saves
fasl files under ~/.cache/common-lisp, where you have write permissions.
--
Dirk
Dirk Sondermann
> On 31/07/11 23:31, Dirk Sondermann wrote:
>> If you are only interested in building a stumpwm binary, you could,
>> as a kludge, keep ASDF from saving fasl files anywhere by inserting
>>
>> (pushnew :broken-fasl-loader *features*)
>>
>> as first line of make-image.lisp (or make-image.lisp.in if you want
>> to rerun configure).
>
> (Sorry, this should've gone in my previous post.)
> Your suggested "kludge" seems to make no difference. :(
That's strange. Are you sure that it is building the binary that fails?
While I would expect 'make stumpwm' to succeed, 'make stumpwm.info' and
thus also 'make' should still fail with the message "permission denied".
--
Dirk