i686 works. The lisp binary is not part of the x86_64 package. Can a x86_64 Dev check this out please?

I have the same problem - x86_64 and no binary after installation.

The problem is that the PKGBUILD uses precompiled i686 binaries. So it doesn't build/work on x86_64. Sources are available though: http://common-lisp.net/project/cmucl/downloads/release/19d/cmucl-src-19d.tar.bz2

From a quick glance, the build process seems to be complicated (not the usual configure;make;make install) and I don't know lisp.

Jürgen: If you can come up with a PKGBUILD that uses the source, I'll build it for x86_64. It might be worthwhile to also update the i686 package as it might benefit from being compiled with the newer gcc and libs. It is also old: no arch field or license. If for some reason you want to stick with the pre-built binaries, cmucl will need to be removed from x86_64 extra.

@Eric: Ok, On my TODO list ;-)
@All: Any Contribution Would Be Appreciated...

From the Build Requirements
--------------------

In order to build CMU CL, you will need:

a) A working CMU CL binary. There is no way around this requirement!

This binary can either be for the platform you want to target, in
that case you can either recompile or cross-compile, or for another
supported platform, in that case you must cross-compile, obviously.


Chicken-Egg Problem: x86_64 doesn't support i686 executables and CMU CL doesn't provide x86_64 binaries.

If you check the PKGBUILD for sbcl, there is:
[ "$CARCH" = "i686" ] && makedepends=('cmucl')
[ "$CARCH" = "x86_64" ] && makedepends=('sbcl')

so we could try building cmucl with sbcl.

Another possibility, that was probably used to build sbcl for x86_64, would be to build an initial cmucl package on x86_64 by using the i686 binaries in a multilib environnement, for example. Once that's done, we can make the future cmucl packages makedepends on the previous cmucl. That would short-circuit the Chicken-Egg Problem if we can get the initial package to build.

Also, I'm wondering if would it be better to remove cmucl from extra x86_64 for the time being to prevent users from downloading/installing it. It's currently unusable. We could readd it when we get a working package.

You cannot build cmucl using sbcl. You need cmucl. I think the option using the multilib environment and a cirular dependency is the best one...

I tried building cmucl using the current PKGBUILD in trunk with multilib packages but I get a "segmentation violation" error:

Compiling GRAY-STREAMS-CLASS...
Loading binary of GRAY-STREAMS-CLASS...
Compiling GRAY-STREAMS...
"pcl:gray-streams-library.x86f" out of date.


Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x0.
[Condition of type SIMPLE-ERROR]

Restarts:
0: [CONTINUE] Return NIL from load of "target:tools/pclcom".
1: [ABORT ] Return to Top-Level.

Debug (type H for help)

(UNIX::SIGSEGV-HANDLER #<unused-arg>
#<unused-arg>
#.(SYSTEM:INT-SAP #x3FFFC86C))
Source:
; File: target:code/signal.lisp
(DEFINE-SIGNAL-HANDLER SIGSEGV-HANDLER "Segmentation Violation")
0]


I'll try on i686 in case it's a non-architecture problem.

I got past the segmentation violation error by updating to 19e. Now I'm getting a:

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

error. Unfortunately, I can't fix that. Our gcc on x86_64 doesn't have 32 bits support. I'm attaching the PKGBUILD and accompanying files. Apart from version bump, I added arch tag, license, FHS man pages and updated patch. That will ease up the update for you. I haven't tested it, BTW.

As for this bug, I think we should just remove the x86_64 package from the repo. I guess users can still use the i686 package in a multilib or chroot environnement.

FYI, cmucl has been removed from extra x86_64.

There is no support for 64-Bit yet:
http://www.cons.org/cmucl/projects.html

Im keeping this open until x86_64 cmucl is out

> Im keeping this open until x86_64 cmucl is out

There are no problems if this task will be closed? To keep clean up the bugtrack. Since there are no work about cmucl in 64 bits systems. Current this task is "fixed" no pkg for x86_64.

@Jürgen - I am going to close this as I guess that there will be a new release when x86_64 support becomes available upstream so you will be reminded then