This is request to expand the keywording of ports in the dev-lisp category. Also included here is a mini how-to. Currently dev-lisp is very x86 centric but it is actually very portable. Most of the ports matching dev-lisp/cl-* are installed into the filesystem as Common Lisp source which is to be compiled later by whatever the Common Lisp compiler the user is using (eg. dev-lisp/cmucl, dev-lisp/sbcl, dev-lisp/openmcl, dev-lisp/clisp). Because most of the ebuilds install plain source files into the user's filesystem, the ebuilds are inherently portable between architectures. However for QA, one really needs to install the port on thier architecture and actually try compiling it with at least one compiler. Here are the compilers available: http://dev.gentoo.org/~mkennedy/common-lisp-keywords.html Note, some of the compilers listed could do with some keywording for other architectures we support. There are two types of dev-lisp/cl-* ebuilds of interest. Ones which depend on dev-lisp/cl-uffi involve the dynamic loading on C language shared libraries at runtime (usually they're Common Lisp bindings to a C library, eg. dev-lisp/cl-sdl) and ones which are purely Common Lisp. With the latter, you can have a great deal of confidence that they will work for each of the compilers listed. If dev-lisp/cl-uffi works on a compiler on your architecture then it is likely that ebuilds depending on it will also work. * To Test a Port Install one or more Common Lisp implementations (eg. dev-lisp/sbcl), then install a port (eg. dev-lisp/cl-ppcre). This will install source into /usr/share/common-lisp/source/cl-ppcre and make a symlink from /usr/share/common-lisp/systems/cl-ppcre.asd to somewhere in /usr/share/common-lisp/source/cl-ppcre. Take note of the ".asd" filename. Then start the Common Lisp implementation you're testing with (eg. /usr/bin/sbcl) and enter a line: (asdf:oos 'asdf:load-op :cl-ppcre) Replace "cl-ppcre" with the actual name part of the ".asd" file you noted previously. If the compilation does not drop you into the debugger (you'll know it when you see it), then the port has compiled successfully. Testing the compiled result is more difficult to describe. If you know how to do it, then proceed. If it works, then the port can be awarded new keywords. If it compiled properly, but you don't know how to test it, then please leave a comment on this bug to that effect. If it didn't compile or compiled and didn't work, then also leave a comment. Members of the Common Lisp Herd can still use this very important information.
lisp devs: please add the arches you want to do keywording to the CC list.
*** Bug 85038 has been marked as a duplicate of this bug. ***
I've succesfully merged and used the following packages on AMD64: dev-lisp/hyperspec-6.0 dev-lisp/gcl-2.6.6 I've succesfully merged but couldn't use the following packages on AMD64: dev-lisp/cl-asdf-1.86-r1 dev-lisp/common-lisp-controller-4.12 dev-lisp/cl-clx-0.6 dev-lisp/cl-mcclim-0.9.20050202 dev-lisp/cl-uffi-1.4.33 cl-asdf doesn't seem to work for gcl (I tried both with and without USE=ansi) and this doesn't seem to be AMD64 related. The packages above, and in fact almost all of the dev-lisp packages, depend on cl-asdf through common-lisp-controller. I've been unable to merge the following packages on AMD64: dev-lisp/clisp-2.33.2-r2 (./clisp-link: line 42: full/lisp.run: No such file or directory) dev-lisp/sbcl-0.8.20 (make-host-1.sh: line 26: sbcl: command not found) dev-lisp/cmucl-19a-r1 (os-common.c:446:2: #error os_control_stack_overflow not implemented for this system gencgc.c:103:2: #error gencgc is not supported on this platform) I've emerge -p'ed some more packages, but most don't like gcl and want to merge another compiler (in particular: sbcl). And as I said, these don't seem to merge for me. ---- Long story short: CLISP and/or SBCL and/or CMUCL need to be made to work on AMD64 and/or GCL needs to be made to work with ASDF before I can test more Lisp packages through normal, Portage means. However, I'm going to try to install the SBCL binary for AMD64 from www.sbcl.org and start testing more Lisp packages that way. Having a working binary SBCL may also allow me to install SBCL from source.
IIRC, GCL 2.6.x isn't ANSI enough to use ASDF. Soon there will be a GCL 2.7.x CVS snapshot in Portage dev-lisp which contains much improved ANSI support. Itt will be able to use the controller stuff as well, ie. dev-lisp/cl-*. I am not sure about CMUCL's amd64 support. I will have to research that more. I am surprised CLISP didn't work. Try disabling all of the USE keywords which represent modules in the CLISP build. (eg. USE='-*' emerge dev-lisp/clisp) Another user (on PPC) reported that building with certain modules enabled will break the build. Unfortunately he did not have enough time to determine which. I have adapted the sbcl-0.8.20 ebuild to support amd64. Unfortunately I don't have a amd64 at the moment to test it on. I've included the patch here. It downloads a AMD64 binary of SBCL and uses that to build SBCL from source (similarly to how we build PPC, MIPS, x86 etc. in the ebuild.).
Created attachment 53459 [details, diff] sbcl-0.8.20.ebuild-amd64-support.patch Initial patch for amd64 support
Matthew, I've just succeeded in building SBCL 0.8.20 with an ebuild I constructed myself (see bug 85274). (But I could unmerge it and test your patch if you'd like?) I was able to emerge and use cl-series. I'll be trying out a lot more libraries tomorrow, and I'll give CLISP another go with your USE-flags suggestion.
I've successfully emerged and used on amd64: * dev-lisp/common-lisp-controller-4.12 * dev-lisp/cl-asdf-1.86-r1 * dev-lisp/sbcl-0.8.20 (had to USE="-callbacks") # dev-lisp/clisp-2.33.2-r2 (had to USE="-X") * dev-lisp/gcl-2.6.6 # dev-lisp/cl-series-2.2.8 # dev-lisp/cl-binary-types-0.90 (The ones with a # are not yet tagged for ~amd64.) I'll be trying out a whole lot more dev-lisp packages in the coming days.
I'm happy to say that the following also work on amd64: # app-emacs/slime-1.0.20050303 # app-emacs/slime-cvs-0-r3
# dev-lisp/cl-sdl-0.2.2-r1 also seems to work fine.
I've been busy this evening going down the first column of `ls dev-lisp/`. Here's what I found for those packages and their dependencies: # dev-lisp/cl-acclaim-0.25 # dev-lisp/cl-acl-compat-1.2.42.20050220 # dev-lisp/cl-aim-1.1 # dev-lisp/cl-aima-1.0.4 # dev-lisp/cl-anaphora-0.9.2 # dev-lisp/cl-araneida-0.9 # dev-lisp/cl-arnesi-1.3 # dev-lisp/cl-aspectl-0.6.4 # dev-lisp/cl-awk-1-r1 # dev-lisp/cl-base64-3.3.1 # dev-lisp/cl-bayescl-20041121 # dev-lisp/cl-blowfish-0.6 # dev-lisp/cl-bouquet-0.1 # dev-lisp/cl-cclan-1.84 # dev-lisp/cl-csv-1.8.1 # dev-lisp/cl-defsystem3-3.3i-r5 # dev-lisp/cl-clx-0.6 # dev-lisp/cl-fare-matcher-1.1-r1 # dev-lisp/cl-fiveam-1.2.3 # dev-lisp/cl-htmlgen-1.2.42.20050220 # dev-lisp/cl-kmrcl-1.78 # dev-lisp/cl-mcclim-0.9.20050202 # dev-lisp/cl-net-telent-date-0.4.1 # dev-lisp/cl-periodic-table-1.0 # dev-lisp/cl-ppcre-1.2.5 # dev-lisp/cl-ptester-2.1.2 # dev-lisp/cl-puri-1.3.1.1 # dev-lisp/cl-regex-1-r1 # dev-lisp/cl-rt-20040621 # dev-lisp/cl-split-sequence-20011114.1-r1 # dev-lisp/cl-trivial-sockets-0.2 # dev-lisp/cl-uffi-1.4.33 # dev-lisp/hyperspec-6.0 All merged, and compiled fine for me in SBCL on AMD64. dev-lisp/cl-albert-0.4.10 is masked for non-platform-related reasons and I didn't try it. dev-lisp/cl-aserve-1.2.42.20050220 failed because it requires multi-threading, and SBCL doesn't yet support threads on non-x86. dev-lisp/cl-chemical-compounds-1.0.2 takes a VERY long time compiling: it seems stuck on (DEFMETA PARSE-QUERY-STRING ...). I killed it after 16 minutes. dev-lisp/cl-clx-sbcl is masked pending removal and I didn't try it.
Created new Bug #85723 for dev-lisp/cl-chemical-compounds sbcl/compilation problem.
Created new Bug #85726 for clisp compilation failure on amd64 with X in USE.
Dirk, I have marked all of Comments 7, 8, and 10 for ~amd64 in CVS. Thanks for taking the time to go through those ports.
Great, Matthew. And here's another batch. ;) # dev-lisp/cl-elephant-0.2.1 # dev-lisp/cl-emb-0.3.0 # dev-lisp/cl-environment-1.0.20021105 # dev-lisp/cl-fad-0.1.2 # dev-lisp/cl-ftp-1.3.1-r1 # dev-lisp/cl-gd-0.4.5 # dev-lisp/cl-getopt-1.1.0 # dev-lisp/cl-hello-0.2 # dev-lisp/cl-html-encode-1.0 # dev-lisp/cl-html-template-0.1.2-r1 # dev-lisp/cl-hyperobject-2.8.8-r1 # dev-lisp/cl-md5-1.8.4 # dev-lisp/cl-sql-3.1.6 # dev-lisp/cl-icu-0.0_p11 # dev-lisp/cl-inflate-1.1.4.2.1-r1 # dev-lisp/cl-interpol-0.1.2 # dev-lisp/cl-irc-0.6.0 # dev-lisp/cl-irc-logger-0.9.2 # dev-lisp/cl-iterate-1.3_pre1 # dev-lisp/cl-plus-1.0 all merged and compiled fine with SBCL 0.8.20 on AMD64. When loading the ASDF system for dev-lisp/cl-jpeg-1.033-r1, SBCL complained "The variable *OPTIMIZE* is unbound." for line 409 of /usr/share/common-lisp/source/cl-jpeg/jpeg.lisp. I'm not exactly sure what causes this. Perhaps the deprecatedness of the EVAL-WHEN keywords on line 71? But this doesn't seem particularly AMD64 related... I'll try SBCL 0.8.20 on x86 tomorrow if somebody doesn't beat me to it. dev-lisp/cl-imho-1.3.2 was masked for non-platform related reasons, and I didn't try it. Oh BTW, emerging dev-lisp/cl-icu-0.0_p11 downgraded dev-libs/icu-3.2 to dev-libs/icu-2.6.2. Is that supposed to happen?
Dirk, I keyworded the batch you listed in Comment #14. dev-lisp/cl-icu-0.0_p11 should not downgrade dev-libs/icu to 2.6.2. Indeed I checked the cl-icu ebuild and it lists ='dev-libs/icu-3.2*' dev-libs/icu-3.2 is keyworded ~amd64. Is it possible you have another port installed (eg. Mono) which wants an earlier version of ICU? dev-libs/icu is not yet slotted for multi-version installs. What kind of result to you have with compiling the dev-lisp/cl-jpeg port on SBCL? On my x86 I see some warnings, but no error condition.
Quick note: a few new libraries where added to Portage late yesterday: dev-lisp/cl-diff dev-lisp/cl-difflib dev-lisp/cl-html-diff dev-lisp/cl-utils-kt dev-lisp/cl-cells dev-lisp/cl-salza dev-lisp/cl-poly-pen
Ehm, my /usr/portage/dev-lisp/cl-icu/cl-icu-0.0_p11.ebuild lists '=dev-libs/icu-2.6*'. I `emerge --sync`ed this morning. I'll try to check out cl-jpeg and the new dev-lisp additions later today.
I don't know what happened yesterday, but now dev-lisp/cl-jpeg-1.033-r1 builds just fine on AMD64 with SBCL 0.8.20. As do: # dev-lisp/cl-cells-20050320 # dev-lisp/cl-diff-0.3 # dev-lisp/cl-difflib-0.1 # dev-lisp/cl-html-diff-0.1 # dev-lisp/cl-osicat-0.4.0 # dev-lisp/cl-salza-0.5 # dev-lisp/cl-utils-kt-20050320 dev-lisp/cl-poly-pen-0.3.1 complained: ; compiling (DEFCLASS SDL-FONT ...)compilation aborted because of fatal error: READ failure in COMPILE-FILE: READER-ERROR at 4592 (line 143, column 25) on #<FILE-STREAM for "file \"/usr/share/common-lisp/source/poly-pen/sdl-renderer.lisp\"" {1001547EA1}>: package "ALIEN" not found But I got the same error on x86. Instead of alien:null-alien, line 143 should use uffi:null-pointer-p, I think. That way, not just CMUCL is supported, but other Lisps as well.
Oddly, dev-lisp/cl-sdl fails on SBCL 0.8.20 on x86 with: ; caught WARNING: ; Duplicate definition for CD-STATUS found in one file. ; See also: ; The ANSI Standard, Section 3.2.2.3 Even though it is a warning, ASDF will enter the debugger before loading the FASL. I'll have to resolve that in order to test the suggested fix for poly-pen on SBCL (which I too, can reproduce).
Keywording all of Comment #18 for ~amd64, except for dev-lisp/cl-poly-pen.
I'm getting the "ASDF treats warnings as errors"-thing now too, on x86 and amd64. Choosing '[ACCEPT ] Continue, treating ... as having been successful.' in the debugger *seems* to be an effective workaround. But no workaround should be needed at all, of course. Any suspects?
BTW, I now have the '=dev-libs/icu-3.2*' line in /usr/portage/dev-lisp/cl-icu/cl-icu-0.0_p11.ebuild, and it no longer wants to downgrade dev-libs/icu.
Another batch, with some weird findings. dev-lisp/cl-kr-2.3.4 dev-lisp/cl-lexer-1-r1 dev-lisp/cl-linedit-0.15.12 dev-lisp/cl-lisp2wish-20040131 dev-lisp/cl-lml-2.5.2-r1 dev-lisp/cl-lml2-1.5.1 (see below) dev-lisp/cl-ltk-0.8.7 (see below) dev-lisp/cl-memoization-1.0 dev-lisp/cl-menusystem-20030919 dev-lisp/cl-meta-0.1.2-r1 dev-lisp/cl-terminfo-1.3 all merged and compiled succesfully with SBCL 0.8.20 on AMD64. /usr/portage/dev-lisp/cl-mel-base-0.5.30.ebuld has KEYWORDS="-*" and I didn't try it. dev-lisp/cl-lambda-gtk-0.1 requires the 'callbacks' USE-flag for SBCL, which I don't have (see bug 85274 comment 7). Oddly, dev-lisp/cl-lambda-gtk-0.1 *does* compile. However, (load "/usr/share/common-lisp/source/lambda-gtk/examples.lisp") then fails, as expected. dev-lisp/cl-lml2-1.5.1 complained: "debugger invoked on a ASDF:MISSING-DEPENDENCY in thread 10935: component LML2-SYSTEM::KMRCL not found, required by #<SYSTEM "lml2" {10049B4111}>" This seems to be a missing dependency in the ebuild, because after emerging dev-lisp/cl-kmrcl-1.78 I could continue the compilation. At some point I got an error saying: "caught ERROR: ; The name of the lambda variable SET is already in use to name a constant." However when I deleted the lml2 FASL files and loaded lml2 again, the compilation completed succesfully. ?:-S I then went on to try dev-lisp/cl-ltk-0.8.7. Here I got the same error, but for FILL instead of SET. So I tried something in the REPL: * (defun foo (&key fill) (print fill)) ; in: LAMBDA NIL ; (SB-INT:NAMED-LAMBDA FOO (&KEY FILL) (BLOCK FOO (PRINT FILL))) ; ==> ; #'(SB-INT:NAMED-LAMBDA FOO (&KEY FILL) (BLOCK FOO (PRINT FILL))) ; ; caught ERROR: ; The name of the lambda variable FILL is already in use to name a constant. ; compilation unit finished ; caught 1 ERROR condition debugger invoked on a SB-INT:COMPILED-PROGRAM-ERROR in thread 10935: Execution of a form compiled with errors. Form: #'(NAMED-LAMBDA FOO (&KEY FILL) (BLOCK FOO (PRINT FILL))) Compile-time-error: The name of the lambda variable FILL is already in use to name a constant. You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. (#:EVAL-TMPFUN-5105 0)[:EXTERNAL] source: (SB-INT:NAMED-LAMBDA FOO (&KEY FILL) (BLOCK FOO (PRINT FILL))) This is in violation of section 11.1.2.1.2.1 of the HyperSpec. I tried the same thing with SET instead of FILL and got the same error. I then tried it on x86 and got the error with FILL but not with SET!! I restarted SBCL on amd64 and didn't get the error for either FILL or SET. I then deleted the ltk FASL files and tried to load ltk again, and it worked! We should probably report this to the SBCL developers mailing list, but I'm not sure what to say. I can't even predictably reproduce the error. BTW, I'm also still seeing the "warnings as errors" thing, so I had to choose ACCEPT in the debugger sometimes to make the above packages build. However, I'm sometimes seeing warnings that *don't* trigger the debugger. Might there be a connection between these two seemingly sporadic bugs?
According to http://article.gmane.org/gmane.lisp.steel-bank.devel/4497, the behaviour of SBCL + ASDF has always been like this. Full warnings are treated as errors, while "lesser" warnings are ignored. But I've never seen this before when compiling common-lisp-controller packages, have you?
Dirk, I see it very frequently. I am actually aware of this behavior. I take the approach of correcting the code which causes the warning condition. If it is not possible (and there are one or two ports like this) then I adjust the system definition file so that the file being compiled or loaded has its warning intercepted. An example of the latter approach can be seen in the Gentoo-specific swank.asd definition. See also: http://www.caddr.com/macho/archives/sbcl-devel/2004-3/3014.html
Matthew do you see the sporadic FILL, SET error thing, or the "warnings as errors" thing? From your message, I assume it's the latter, and I'll keep an eye out for those warnings when I try the following batches of dev-lisp/* stuff. I'm still at a loss about the former bug though...
dev-lisp/cl-modlisp-0.6 dev-lisp/cl-ncurses-0.1.1 dev-lisp/cl-org-davep-cldict-1.1 dev-lisp/cl-org-davep-dict-2.3 dev-lisp/cl-org-davep-dictrepl-2.2 dev-lisp/cl-org-davep-newsrc-2.0 dev-lisp/cl-org-davep-nntp-2.0 dev-lisp/cl-paip-1.0.2 dev-lisp/cl-parse-number-1.0-r1 dev-lisp/cl-pg-20050202 dev-lisp/cl-pipes-1.2.1 dev-lisp/cl-png-0.4 dev-lisp/cl-postoffice-1.8.2.3 dev-lisp/cl-prevalence-20040709 dev-lisp/cl-pxmlutils-0.0.9-r2 dev-lisp/cl-quick-arrays-1.0-r1 dev-lisp/cl-s-xml-20050202 all emerged and compiled fine with SBCL 0.8.20 on AMD64. dev-lisp/cl-odcl-1.3.5 failed to compile with: Lock on package COMMON-LISP violated when binding DIGIT-CHAR-P as a local function. See also: SBCL Manual, Package Locks [node] Common Lisp Hyperspec, 11.1.2.1.2 [section]
dev-lisp/cl-port-1.0.1.2-r2 dev-lisp/cl-resolver-0.7 dev-lisp/cl-rfc2388-20041228 dev-lisp/cl-rsm-queue-1.1a dev-lisp/cl-rsm-bitcomp-1.1-r1 dev-lisp/cl-rsm-cache-1.1_beta1-r1 dev-lisp/cl-rsm-delayed-1.0-r1 dev-lisp/cl-rsm-filter-1.1_beta2-r1 dev-lisp/cl-rsm-finance-1.1-r1 dev-lisp/cl-rsm-fuzzy-1.2-r2 dev-lisp/cl-rsm-memo-1.1.1-r1 dev-lisp/cl-rsm-mod-1.2 dev-lisp/cl-rsm-modal-1.0-r1 dev-lisp/cl-rsm-mpoly-1.1 dev-lisp/cl-rsm-queue-1.1a dev-lisp/cl-rsm-rand-1.2-r1 dev-lisp/cl-rsm-random-1.1-r1 dev-lisp/cl-rsm-rsa-1.3.20040328 dev-lisp/cl-rsm-string-1.3 dev-lisp/cl-s-xml-rpc-20040709 dev-lisp/cl-scribble-1.16.1 dev-lisp/cl-sha1-1.0-r1 dev-lisp/cl-ssl-0.2.2004.01.04 dev-lisp/cl-statistics-1.0.0.2-r1 dev-lisp/cl-syslog-0.9.1-r1 dev-lisp/cl-tclink-3.3.1-r1 dev-lisp/cl-trivial-http-1.1 dev-lisp/cl-url-rewrite-0.1.0 dev-lisp/cl-xmls-1.2 all emerged and compiled fine with SBCL 0.8.20 on AMD64. dev-lisp/cl-rsm-bool-comp-1.0, dev-lisp/cl-rsm-gen-prog-1.0-r1, and dev-lisp/cl-rsm-genetic-alg-1.0 were all masked and I didn't try them. dev-lisp/cl-rss-0.1.1 failed to compile with: MAKE-PROCESS-LOCK: Calling a multiprocessing function on a single-threaded sbcl build [Condition of type SIMPLE-ERROR] dev-lisp/cl-tbnl-0.5.2 failed to compile with: The lambda-list (RFC2388::SOURCE RFC2388::BOUNDARY &KEY RFC2388::RECURSIVE-P RFC2388::WRITE-CONTENT-TO-FILE) is incompatible with existing methods of #<STANDARD-GENERIC-FUNCTION RFC2388:PARSE-MIME (2)>. [Condition of type SIMPLE-ERROR]
dev-lisp/cl-ubf-0.2.1-r1 dev-lisp/cl-unit-1.3.1-r1 dev-lisp/cl-who-0.5.0 dev-lisp/cl-xlunit-0.6.2 dev-lisp/cl-xml-psychiatrist-0.4 dev-lisp/cl-xmls-valid-0.1.0 dev-lisp/cl-xptest-1.2.3-r1 dev-lisp/cl-yaclml-0.5.2 all emerged and compiled fine with SBCL 0.8.20 on AMD64. dev-lisp/cl-webactions-1.2.42.20050220 failed to compile: debugger invoked on a SIMPLE-ERROR in thread 10490: MAKE-PROCESS-LOCK: Calling a multiprocessing function on a single-threaded sbcl build dev-lisp/cl-zebu-3.5.5 is masked and I didn't try it.
And here's the last batch of dev-lisp/ trials on AMD64. dev-lisp/cmucl-19a-r1 failed to build, as was to be expected on AMD64: ../../src/lisp/os-common.c:446:2: #error os_control_stack_overflow not implemented for this system ../../src/lisp/gencgc.c:103:2: #error gencgc is not supported on this platform gmake[1]: *** [Depends] Error 1 gmake[1]: Leaving directory `/var/tmp/portage/cmucl-19a-r1/work/cmucl-19a-release-20040728.orig/target/lisp' make: *** [all] Error 2 dev-lisp/cmucl-source-19a also failed to merge: rm -rf target || true ./src/tools/create-target.sh target linux_gencgc x86 || true Lisp = linux_gencgc Motif = x86 ./src/tools/build-world.sh target ./src/tools/build-world.sh: line 24: lisp: command not found make: *** [all] Error 127 dev-lisp/drscheme-209 failed to merge as well: setup-plt: Error during Compiling .zos for sgl (/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/sgl) setup-plt: default-load-handler: cannot open input file: "/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/sgl/gl-vectors/gl-double-vector.ss" (No such file or directory; errno=2) setup-plt: Error during Early Install for SSL Driver (/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/openssl) setup-plt: make: Failed to make compiled/native/x86_64-linux/mzssl.so; link-extension: command failed setup-plt: Error during Early Install for homogeneous-vectors (/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/srfi/4) setup-plt: make: Failed to make compiled/native/x86_64-linux/homo-f64-vector-prims.so; make: Failed to make compiled/native/x86_64-linux/homo-f64-vector-prims.so; link-extension: command failed setup-plt: Error during Early Install for sgl (/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/sgl) setup-plt: make: Failed to make gl-vectors/compiled/native/x86_64-linux/gl-double-vector.so; link-extension: command failed setup-plt: Error during Early Install for Plot library (/var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/plot) setup-plt: make: Failed to make /var/tmp/portage/drscheme-209/image/usr/share/drscheme/collects/plot/compiled/native/x86_64-linux/fit-low-level.so; link-extension: command failed install: Errors in compilation process! (1) make[1]: *** [copy-finish] Error 1 make[1]: Leaving directory `/var/tmp/portage/drscheme-209/work/plt/src' make: *** [install] Error 2 dev-lisp/ecls-0.9e merged fine and seems to work. dev-lisp/ecls-cvs-1 failed to merge at the very last moment: mkdir -p -- /usr/share/doc/ecl ACCESS DENIED mkdir: /usr/share/doc/ecl mkdir: cannot create directory `/usr/share/doc/ecl': Permission denied make[2]: *** [install] Error 1 make[2]: Leaving directory `/var/tmp/portage/ecls-cvs-1/work/ecls/build/doc' make[1]: *** [install] Error 2 make[1]: Leaving directory `/var/tmp/portage/ecls-cvs-1/work/ecls/build' make: *** [install] Error 2 man: info: gzipping GNU info page: ecldev.info gzipping GNU info page: ecl.info >>> Completed installing ecls-cvs-1 into /var/tmp/portage/ecls-cvs-1/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-dev-lisp_-_ecls-cvs-1-22472.log" mkdir: /usr/share/doc/ecl -------------------------------------------------------------------------------- # cat "/tmp/sandbox-dev-lisp_-_ecls-cvs-1-22472.log" mkdir: /usr/share/doc/ecl dev-lisp/gcl-cvs-2.7.0 spewed some errors, but the merge was reported as successful, and it seems to work. COMMON-LISP-CONTROLLER> Error in MAKE-PATHNAME [or a callee]: Invalid directory in pathname #P(:DIRECTORY (:RELATIVE "root" NIL)). Fast links are on: do (use-fast-links nil) for debugging Broken at MAKE-PATHNAME. Type :H for Help. 1 (Continue) Return to top level. dbl:COMMON-LISP-CONTROLLER>> SEND-CLC-COMMAND dbl:COMMON-LISP-CONTROLLER>> Error in IN-PACKAGE [or a callee]: A package error occurred on "ASDF": "No such package". Fast links are on: do (use-fast-links nil) for debugging Broken at IN-PACKAGE. 1 (Continue) 2 (Abort) Return to debug level 1. 3 Return to top level. dbl:COMMON-LISP-CONTROLLER>>> RUN-SHELL-COMMAND dbl:COMMON-LISP-CONTROLLER>>>chown: `cl-builder:cl-builder': invalid user /usr/portage/eclass/common-lisp-common.eclass: line 68: clc-autobuild-check: command not found ... BTW, I neglected to report www-apache/mod_lisp-2.42 building fine, when trying out the packages depending on it.
Dirk, do you have any ideas with respect to Bug #87849 sbcl-0.8.20 fails to (merge with error about lib64)?
I have keyworded to ports mentioned in Comment #23
I have keyworded to ports mentioned in Comment #27 and included a fix for the cl-odcl compilation problems.
Dirk, Everything listed has been keyworded for ~amd64. In fact I got access to a ppc and keyworded for ~ppc as well. At the same time, I keyworded everything which was ~x86 and reasonably well tested to x86. I think the dev-lisp/ category is much improved shape now. Thank you very much for working with me on the AMD64 keywording. There are some unresolved issued in this bug (I need to go through comments and make sure I've created new bugs for each bug you came across). After I have resolved those, I will close this bug.
Sounds good Matthew.
matthew: i hope you still have an overview, i completely lost it :S however, i think ~amd64 keywording has finished, so i'm removing amd64@g.o. If i'm wrong, please readd
This is pretty much complete now.
Thank you for your help to all those involved.
