[Openmcl-devel] OpenMCL 1.0-rc1

Gary Byers gb at clozure.com
Sun Sep 25 06:36:20 PDT 2005



On Sun, 25 Sep 2005, R. Mattes wrote:

> On Sat, 2005-09-24 at 18:13 -0600, Gary Byers wrote:
>> There are now "full" (sources+binaries+interfaces) 1.0-rc1-050924
>> archives available in the testing directory on clozure.com
>> (<ftp://clozure.com/pub/testing/>), as well as archives containing
>> heap images for 32-bit Darwin, 64-bit Darwin, and 32-bit Linux.
>
> Just downloaded the tarball but unfortunately the binary (ppccl)
> has rather restricting library dependencies:
>
>  ldd ppccl
>  ./ppccl: /lib/libc.so.6: version `GLIBC_2.3.4' not found (required
> by ./ppccl)
>  ./ppccl: /lib/libpthread.so.0: version `GLIBC_2.3.4' not found
> (required by ./ppccl)
>  ./ppccl: /lib/libpthread.so.0: version `GLIBC_2.3.3' not found
> (required by ./ppccl)
> 	libdl.so.2 => /lib/libdl.so.2 (0x0fd50000)
> 	libm.so.6 => /lib/libm.so.6 (0x0fde0000)
> 	libpthread.so.0 => /lib/libpthread.so.0 (0x0fd70000)
> 	libc.so.6 => /lib/libc.so.6 (0x0fe70000)
> 	/lib/ld.so.1 => /lib/ld.so.1 (0x0ffd0000)
>
>
> Is this really neccessary? (My test box is a G4 running Ubuntu Linux/PPC
> stable),

Well, the kernel shouldn't care -too- much about the glibc version.
I'm not sure if there's a good way to tell the linker that; the makefile
isn't explicitly asking for specific versions of the libraries (at least
not intentionally.)

>
>> The "full" Darwin archive contains 32-bit and 64-bit kernels and
>> heap images; the 64-bit image is fairly large and might be of limited
>> interest, so we might want to think about other ways of packaging
>> things.
>>
>> These are supposed to be "release candidates", i.e., the only changes
>> between now and the final 1.0 release should be in response to any
>> critical (showstopper) bugs.  The CVS metainformation in the archives
>> is from the bleeding-edge tree; as 1.0 nears release, the code should
>> all migrate into the main tree, and the "ccl" directory installed from
>> these archives should probably be replaced with the official release
>> when it becomes available.
>
> Can i recompile the tarball using a CVS checkout?

The tarball contains/is a CVS checkout, so you should be able to just
do:

cd ccl/lisp-kernel/linux
make clean
make


That'll get you to to the next problem, which is that the PPCCL image
in the linux-1.0-rc1-050924 archive isn't a 32-bit Linux image.  (I
suspect that the standalone ppccl-image-050924.tar.gz contains the
same thing.)

I just recompiled the kernel on a system that seems to have something
halfway between glibc-2.3.1 and 2.3.2 installed.  That seems to run
fine on newer systems as well, though at the moment I don't know how
to advise the linker that even older versions of the C and thread
libraries would be fine, or even if that's possible.

I rebuilt the "openmcl-linuxppc-all-1.0-rc1-050924" archive with
that kernel and a working 32-bit Linux heap image.  I saved that
as

<ftp://clozure.com/pub/testing/openmcl-linuxppc-all-1.0-rc1-050924-p1.tar.gz>

and put the working 32-bit Linux heap image in:

<ftp://clozure.com/pub/testing/ppccl-image-050924-p1.tar.gz>

The Darwin archives seem to be OK.

>
> Cheers, Ralf Mattes
>

For anyone in the same position as Ralf (downloaded the pre-p1 archives
and find that the distributed kernel requires newer libraries than those
that they have installed), just doing a "make" in ccl/lisp-kernel/linux
should fix things, to that point.

Anyone at that point (downloaded the pre-p1 archives, has a working
kernel, but that kernel complains that it can't load the PPCCL image)
can get a new (correct) image from:

<ftp://clozure.com/pub/testing/ppccl-image-050924-p1.tar.gz>

Any Linux user who hasn't yet downloaded the 1.0-rc1 release and wants
to do so can get the whole shebang from:

<ftp://clozure.com/pub/testing/openmcl-linuxppc-all-1.0-rc1-050924-p1.tar.gz>

That should get us all to the point of seeing what's broken and what's new.

I didn't change anything in the source (the "Welcome" banner announces
the lisp as version 1.0-rc1-050924), since these seemed to have been
packaging bugs.

Sorry.



More information about the Openmcl-devel mailing list