Hi,
I just wanted to know if my installation of cmucl 18c under redhat 7.0
has any hidden problems.
It just seems too easy. All that I heard referenced to on this form was
painful sounding installs using
Dabein packages etc. If it really is this easy, why isn't it talked
about more? I'm sure that more people
would use cmucl if this is all that there is to it. All that I did to
install it was (done as "root" of course):
1. Download the tarballs for cmucl-18c that use glib21. This included
the basic, extras, docs and
source. (The source really isn't needed but I found that, that is where
the good version of the xlib
demo program "menu.lisp" is.) (Actually the docs aren't needed either
but they are nice to have. I also
use this doc directory to keep the CMU encyclopedia etc. downloaded from
other sites.)
2. Expand the tarballs in /usr/local/lib/cmucl-18c/
The "doc" tarball needed to be expanded into a "doc" sub directory, all
of the others created their own
sub directories.
3. Copy the "sample-wrapper" that you will find in ../cmucl-18c/bin/
to /usr/local/bin and rename it what ever name you want to call lisp.
This directory is in the standard path so
linux will find it here. Edit this file and change the
"/<<your-cmucl-path>>/"
at the two locations to "/usr/local/lib/cmucl-18c/". In other words
Change:
CMUCLLIB=/<<your-cmucl-path>>/lib
To:
CMUCLLIB=/usr/local/lib/cmucl-18c/lib
And Change:
exec /<<your-cmucl-path>>/bin/lisp ··@"
To:
exec /usr/local/lib/cmucl-18c/bin/lisp ··@"
I've haven't done anything with the entry that talks about a temp file.
Exactly when would this be used and
what would be the best way to set this up in Linux? All of this would be
easy to change later so don't sweat it.
4. Change directory to /usr/local/lib/cmucl-18c/lib and run ./config
I enabled everything except "motif and graphical debugger" since Motif
(lesstif) is not part of Red Hat's standard
installation. This creates a new lisp.core with these configurations and
it made a backup of the original. (It is good
to make a copy first that is explicitly labeled as the original version
that has the safest configuration.)
This is all that it took. If it is really this simple why didn't anyone
tell me sooner? I've run small programs and
had no problems yet.
Actually my install is a little more complicated but it works installed
like I said. On my system I named
the sample-wrapper cmucl-18c and made soft links for it called "cmucl"
and "lisp" so I can call it multiple ways.
This is one advantage of this type of install, if you have other lisps
which all want to be called "lisp" you can
just rename the wrapper. I also have a soft link for the "cmucl-18c"
directory just called "cmucl". I originally got
this from a statement about how a cmu system was set up (using
/usr/local/lib/cmucl/) but I don't know if it is
important.
Gary
g-c-r-a-i-g-at-n-b-dot-n-e-t
On Tue, 13 Feb 2001 22:17:29 -0500, Jerry Gregg <······@nowhere.net> wrote:
> use this doc directory to keep the CMU encyclopedia etc. downloaded from
I am working on a new version.
> I enabled everything except "motif and graphical debugger" since Motif
> (lesstif) is not part of Red Hat's standard
> installation. This creates a new lisp.core with these configurations and
You don't need Motif/Lesstif for this on your Red Hat system because Motif
is statically linked to CMU CL (or this was the case with 18b: is it still
so?).
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Michael Kappert
Subject: Re: cmucl on linux (redhat 7.0) easy install.
Date:
Message-ID: <3A8AFE60.FD9C6499@iitb.fhg.de>
Paolo Amoroso wrote:
> > I enabled everything except "motif and graphical debugger" since Motif
> > (lesstif) is not part of Red Hat's standard
> > installation. This creates a new lisp.core with these configurations and
>
> You don't need Motif/Lesstif for this on your Red Hat system because Motif
> is statically linked to CMU CL (or this was the case with 18b: is it still
> so?).
No, 18c comes with a dynamically linked motifd.
On my Caldera system, which doesn't have lesstif either,
I'm using the statically linked motifd from CMU CL 18b.
Michael
--
Paolo Amoroso <·······@mclink.it> writes:
> On Tue, 13 Feb 2001 22:17:29 -0500, Jerry Gregg <······@nowhere.net> wrote:
>
> > use this doc directory to keep the CMU encyclopedia etc. downloaded from
>
> I am working on a new version.
>
>
> > I enabled everything except "motif and graphical debugger" since Motif
> > (lesstif) is not part of Red Hat's standard
> > installation. This creates a new lisp.core with these configurations and
>
> You don't need Motif/Lesstif for this on your Red Hat system because Motif
> is statically linked to CMU CL (or this was the case with 18b: is it still
> so?).
No, the 18c releases (at least on x86/Linux) have a motifd that is
dynamically linked against 1.x Motif/Lesstif. It should work both
with real 1.x Motif as well as 1.x Lesstif. AFAIK OpenMotif won't
work, because it only included 2.x libraries.
At least in my case this was done in order to allow users to choose
which Motif to use: Real Motif is more conforming (by definition) in
a number of areas, but it is much slower than Lesstif. And then there
are the licensing restrictions.
But then again I didn't introduce this policy, I just followed the
lead from DTC's original glibc22 release.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
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
--------------3C026225B6D2F240937415EF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Paolo Amoroso wrote:
> On Tue, 13 Feb 2001 22:17:29 -0500, Jerry Gregg <······@nowhere.net> wrote:
>
> > use this doc directory to keep the CMU encyclopedia etc. downloaded from
>
> I am working on a new version.
>
> > I enabled everything except "motif and graphical debugger" since Motif
> > (lesstif) is not part of Red Hat's standard
> > installation. This creates a new lisp.core with these configurations and
>
> You don't need Motif/Lesstif for this on your Red Hat system because Motif
> is statically linked to CMU CL (or this was the case with 18b: is it still
> so?).
>
> Paolo
>
I'am really interrest of having your new install. Because I tried it a lot of
times with lots of README... and I failed all the time. What drive me to use
the pre-compiled tarball, but I need a normal-core image instead of a
safe-core, but I dont know the way to do that. Maybe with the install I guess
??
--------------3C026225B6D2F240937415EF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Paolo Amoroso wrote:
<blockquote TYPE=CITE>On Tue, 13 Feb 2001 22:17:29 -0500, Jerry Gregg &·········@nowhere.net>
wrote:
<p>> use this doc directory to keep the CMU encyclopedia etc. downloaded
from
<p>I am working on a new version.
<p>> I enabled everything except "motif and graphical debugger" since Motif
<br>> (lesstif) is not part of Red Hat's standard
<br>> installation. This creates a new lisp.core with these configurations
and
<p>You don't need Motif/Lesstif for this on your Red Hat system because
Motif
<br>is statically linked to CMU CL (or this was the case with 18b: is it
still
<br>so?).
<p>Paolo
<br><a href="http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/"></a> </blockquote>
I'am really interrest of having your new install. Because I tried it a
lot of times with lots of README... and I failed all the time. What drive
me to use the pre-compiled tarball, but I need a normal-core image instead
of a safe-core, but I dont know the way to do that. Maybe with the install
I guess ??</html>
--------------3C026225B6D2F240937415EF--
>>>>> "Iban" == Iban Hatchond <········@emi.u-bordeaux.fr> writes:
Iban> I'am really interrest of having your new install. Because I
Iban> tried it a lot of times with lots of README... and I failed
Iban> all the time. What drive me to use the pre-compiled tarball,
Iban> but I need a normal-core image instead of a safe-core, but I
Iban> dont know the way to do that. Maybe with the install I guess
Why do you need the normal-core instead of the safe-core?
Ray
Raymond Toy wrote:
> >>>>> "Iban" == Iban Hatchond <········@emi.u-bordeaux.fr> writes:
>
> Iban> I'am really interrest of having your new install. Because I
> Iban> tried it a lot of times with lots of README... and I failed
> Iban> all the time. What drive me to use the pre-compiled tarball,
> Iban> but I need a normal-core image instead of a safe-core, but I
> Iban> dont know the way to do that. Maybe with the install I guess
>
> Why do you need the normal-core instead of the safe-core?
>
> Ray
I did a window-manager with cmu-cl and clx. I have a segfault when i
catch a configure-request event. (I try to redo that segfault with a
small
program but i never happened)
I restart it with a normal-core, and the segfault disappear. I still dont
understand.
So if you have any idea.
If you want a tarball with the WM, ask me. (Because I had no time to work
on a web-page for it)
Iban Hatchond wrote:
> Raymond Toy wrote:
>
>> >>>>> "Iban" == Iban Hatchond <········@emi.u-bordeaux.fr> writes:
>>
>> Iban> I'am really interrest of having your new install. Because I
>> Iban> tried it a lot of times with lots of README... and I failed
>> Iban> all the time. What drive me to use the pre-compiled tarball,
>> Iban> but I need a normal-core image instead of a safe-core, but I
>> Iban> dont know the way to do that. Maybe with the install I guess
>>
>> Why do you need the normal-core instead of the safe-core?
>>
>> Ray
>
> I did a window-manager with cmu-cl and clx. I have a segfault when i
> catch a configure-request event. (I try to redo that segfault with a
> small
> program but i never happened)
> I restart it with a normal-core, and the segfault disappear. I still dont
>
> understand.
> So if you have any idea.
You may try to remove all declarations first and then try to add them part
for part.
You should also try to compile your code with
(proclaim '(optimize (speed 0) (safety 3) (debug 3)))
As I experienced segfaults appear in CMUCL mostly in three cases:
a) CMUCL has a bug => Bugreport after finding the offending part
b) A wrong declaration
c) Buggy FFI code
> If you want a tarball with the WM, ask me. (Because I had no time to work
>
> on a web-page for it)
Yes - please can you send it to ···@dataheaven.de?
Jochen
Iban Hatchond <········@emi.u-bordeaux.fr> writes:
> I'am really interrest of having your new install. Because I tried it a lot of
> times with lots of README... and I failed all the time. What drive me to use
> the pre-compiled tarball, but I need a normal-core image instead of a
> safe-core, but I dont know the way to do that. Maybe with the install I guess
> ??
Since only the Debian packages by Peter Van Eynde have a safe-core,
I'm asuming you are using them, either directly or via alien, correct?
In that case getting a normal core should be easy, since Peter
normally has packages for safe, normal, and some other cores (small?
fast? I don't remember exactly). So just installing the normal core
package in addition should be sufficient.
OTOH you could also use the 18c release tarballs directly, available
at http://www.cons.org/cmucl/ . Since last week the 18c release
binaries for x86/Linux at least are normal cores (instead of small
cores, like they were before that).
Either way getting a "normal" core should be easy, if that is what you
desire.
Recompiling CMU CL using an existing installation is also fairly
straight-forward using Peter's debian packages: Just get the source
package for cmucl, which can be rebuild with a simple call to make.
If you select the right setenv-*.lisp file (either by hand or by a
call to make, see the Makefile), you should be able to build a normal
core without problems.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
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
First of all concerning the easy install that I posted: Remember that you can use
the sample-wrapper to rename lisp
something else but you need to have cmucl named lisp and findable by linux when you
run ./config. After that you
can name it whatever you want.
(see below for more comments)
"Pierre R. Mai" wrote:
> Iban Hatchond <········@emi.u-bordeaux.fr> writes:
>
> > I'am really interrest of having your new install. Because I tried it a lot of
> > times with lots of README... and I failed all the time. What drive me to use
> > the pre-compiled tarball, but I need a normal-core image instead of a
> > safe-core, but I dont know the way to do that. Maybe with the install I guess
> > ??
>
> Since only the Debian packages by Peter Van Eynde have a safe-core,
> I'm asuming you are using them, either directly or via alien, correct?
>
> In that case getting a normal core should be easy, since Peter
> normally has packages for safe, normal, and some other cores (small?
> fast? I don't remember exactly). So just installing the normal core
> package in addition should be sufficient.
>
> OTOH you could also use the 18c release tarballs directly, available
> at http://www.cons.org/cmucl/ . Since last week the 18c release
> binaries for x86/Linux at least are normal cores (instead of small
> cores, like they were before that).
>
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).
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.?
Second of all I'm very surprised that something like this would change in the
tarballs without
any indication.
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. 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.
I would appreciate anything you could do along these lines. Let me know if you have
any advice. In the mean
time I will continue to do my part and try to develop applications in cmucl. I have
been messing with operating
systems and installations for far too long.
>
> Either way getting a "normal" core should be easy, if that is what you
> desire.
>
> Recompiling CMU CL using an existing installation is also fairly
> straight-forward using Peter's debian packages: Just get the source
> package for cmucl, which can be rebuild with a simple call to make.
> If you select the right setenv-*.lisp file (either by hand or by a
> call to make, see the Makefile), you should be able to build a normal
> core without problems.
>
> Regs, Pierre.
>
> --
> Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
> 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
Jerry Gregg <······@nowhere.net> writes:
> 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.
> 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.
> 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.
> 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].
> 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.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
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
Thanks you have been very helpful.
Gary
"Pierre R. Mai" wrote:
> Jerry Gregg <······@nowhere.net> writes:
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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].
>
> > 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.
>
> --
> Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
> 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
no no no spam -g-c-r-a-i-g-at-n-b-dot-n-e-t-
From: Will Deakin
Subject: Re: cmucl on linux (redhat 7.0) easy install.
Date:
Message-ID: <3A912FC5.4070406@pindar.com>
Pierre R. Mai wrote:
> Recompiling CMU CL using an existing installation is also fairly
> straight-forward using Peter's debian packages: Just get the source
> package for cmucl, which can be rebuild with a simple call to make.
> If you select the right setenv-*.lisp file (either by hand or by a
> call to make, see the Makefile), you should be able to build a normal
> core without problems.
In my experience this is very true.
I have had problems compiling small <-> normal/safe cores but not
safe<->normal core compilation. However, YMMV.
:)will