cmucl on linux (redhat 7.0) easy install.
Quote:
> When I first did the easy install I used the tarballs from a couple
> of weeks ago which seem to have the small cores. I re-downloaded the
> tarballs and reinstalled it. Now I have what I guess is the normal
> cores (the core and the files in the subsystems directories are
> considerably bigger).
Yes, that is correct.
Quote:
> First of all I am not sure of the implications of the small core vs
> normal core. Is this a function of the memory models used, and hence
> effects the limits of array sizes etc.?
No, the only differences are the optimization settings used to compile
the lisp code (library stuff, compiler, etc.) that goes into the
core. With a small core the internal and external safety and debug
settings are reduced, and more stuff is byte-compiled rather than
compiled to native code.
So in theory there should be no user-observable differences in
behaviour between small and normal cores for correct code.
OTOH small cores will not offer the same level of information in the
face of incorrect code, which can make debugging more confusing for
people not familiar with CMU CL. It was this problem that prompted
the changeover to non-small cores.
The recompile was also necessary because of a release glitch in 18c:
The x86/linux binaries were the only ones to still include the :cmu17
feature on *features*, while all other binaries had dropped :cmu17.
Note that these are all build-time configuration issues, and that no
source-code changes have been applied.
Quote:
> Second of all I'm very surprised that something like this would
> change in the tarballs without any indication.
Yes, this is a non-ideal situation. Currently some discussions are
going on in the cmucl mailing lists about reorganizing the release
area, and once that is completed maybe a new release announcement
should be posted.
Quote:
> I don't want to sound like I'm complaining. I appreciate the work
> that the maintainers put into the package, but to bring more people
> on board I think that an easier to install package would go a long
> way.
While I agree that the current situation of released binaries changing
after the release is not at all ideal, I don't think that there have
been any problems with installing the release binaries (either old or
new)[1].
Quote:
> I had heard that a lot of people were running older (buggy) versions
> of cmucl just because of install problems. I even started running it
> on freeBSD until it became apparent that freeBSD would never drive
> my display (Intel i810 based). It makes little difference if cmucl
> is easier to install on some flavor of an OS if that OS is harder to
> install on your machine. Redhat handles a lot of different types of
> hardware with little problem. That is why it is so popular and that
> is also why I was hoping to come up with an easier install that
> could be used with Redhat.
Well CMU CL should be easy to install on all platforms that have
released binaries. In the past there was a time when we fought with
the libc 5.x => glibc 2.0 => glibc 2.1 incompatibilities on Linux.
Since current versions of glibc at least offer binary backward
compatibility, this issue hopefully won't crop up again.
So if there are any specific install problems with the current release
binaries, please bring them up, either in this forum, and/or the cmucl
mailing lists, and/or via private mail.
Regs, Pierre.
Footnotes:
[1] There have been reports that some 2.2 Linux kernels will prohibit
CMU CL from running, when compiled with CONFIG_2GB, since this
will change the memory map as seen by user-processes. At the
current time it seems that some (patched?) 2.2 kernels don't
exhibit this problem, and that maybe 2.4 kernels will also not
exhibit the problems. Other than that I'm not aware of install
problems for 18c on x86/linux.
--
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein