xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'm trying to get cmucl running on Red Hat 6.0, thus far without success.
I've tried the folowing thus far:
1) install the linux binaries from
ftp://ftp2.cons.org/pub/languages/lisp/cmucl/release/
2) install the debian package
1) After unpacking the binaries cmucl-18b.linux.glibc2.extra.tgz
and cmucl-18b.linux.glibc2.tgz and installing them in
/usr/local/lib/cmucl I set up and export an environment variable
CMUCLLIB to point to /usr/local/lib/cmucl/lib. And call
/usr/local/lib/cmucl/bin-lisp This is essentially the same as
what I once did with 18a on a solaris sparc 5, where I've been
happily lisping away ever since. On the linux machine I get the
message:
/usr/local/lib/cmucl/bin/lisp: error in loading shared libraries:
/usr/local/lib/cmucl/bin/lisp: undefined symbol: __setfpucw
2) Then I found http://www.telent.net/lisp/howto.html and pointers to
the debian binaries. As I have glibc-2.1.1-6 I downloaded the packages
from http://www.debian.org/Packages/ unstable/devel/cmucl.html
and http://www.debian.org/Packages/unstable/devel/cmucl-normal.html
I also got ftp://ftp.redhat.com/pub/contrib/noarch/alien-6.53-3.noarch.rpm
When I try to convert the debian packages to Red Hat packages,
alien reports errors and doesn't build the rpms:
# alien --to-rpm cmucl_2.4.20.deb
-- Examining cmucl_2.4.20.deb
tar: control: Not found in archive
tar: Error exit delayed from previous errors
-- Unpacking cmucl_2.4.20.deb
-- Automatic spec file generation
-- Building the package --2.i386.rpm
--2.spec: unknown option
alien: Error putting together the RPM package.
# alien --to-rpm cmucl-normal_2.4.20.deb
-- Examining cmucl-normal_2.4.20.deb
tar: control: Not found in archive
tar: Error exit delayed from previous errors
-- Unpacking cmucl-normal_2.4.20.deb
-- Automatic spec file generation
-- Building the package --2.i386.rpm
--2.spec: unknown option
alien: Error putting together the RPM package.
I would naively assume that the messages 'tar: control: Not found in archive'
and '--2.spec: unknown option' are important here, but I don't know how
to interpret them.
I believe that I have everything that alien needs to do what I want. I have:
perl 5.005_03
RPM version 3.0.2
Any ideas what I should try now?
Thanks,
George Smith
······@bloomfield.phil1.uni-potsdam.de
Institut fuer Germanistik
Universitaet Potsdam
In article <··············@bloomfield.phil1.uni-potsdam.de>,
George Smith <······@rz.uni-potsdam.de> wrote:
>
> When I try to convert the debian packages to Red Hat packages,
> alien reports errors and doesn't build the rpms:
>
> # alien --to-rpm cmucl_2.4.20.deb
> -- Examining cmucl_2.4.20.deb
> tar: control: Not found in archive
> tar: Error exit delayed from previous errors
> -- Unpacking cmucl_2.4.20.deb
> -- Automatic spec file generation
> -- Building the package --2.i386.rpm
> --2.spec: unknown option
> alien: Error putting together the RPM package.
I think this is because the tarball inside the debian package has
the files control listed as "./control". The alien conversion cannot
find the control file because it looks for "control" exactly, or
something along those lines. I took the debian file apart and installed
it manually.
Sent via Deja.com http://www.deja.com/
Before you buy.
Jon Dyte <·······@my-deja.com> writes:
> I think this is because the tarball inside the debian package has
> the files control listed as "./control". The alien conversion cannot
> find the control file because it looks for "control" exactly, or
> something along those lines. I took the debian file apart and installed
> it manually.
I've done the same now and a lisp process is up and running.
Thanks again to all who responded!
George Smith
······@bloomfield.phil1.uni-potsdam.de
Institut fuer Germanistik
Universitaet Potsdam
On 10 Jul 2000 12:35:34 +0200, George Smith <······@rz.uni-potsdam.de>
wrote:
> I'm trying to get cmucl running on Red Hat 6.0, thus far without success.
> I've tried the folowing thus far:
>
> 1) install the linux binaries from
> ftp://ftp2.cons.org/pub/languages/lisp/cmucl/release/
[...]
> /usr/local/lib/cmucl/bin/lisp: error in loading shared libraries:
> /usr/local/lib/cmucl/bin/lisp: undefined symbol: __setfpucw
This is a known problem. CMU CL 18b for Linux relies on an undocumented
feature of glibc 2.0.x that changed in an incompatible way in glibc 2.1.x,
which is shipped with Red Hat 6.x.
> 2) Then I found http://www.telent.net/lisp/howto.html and pointers to
> the debian binaries. As I have glibc-2.1.1-6 I downloaded the packages
[...]
> I also got ftp://ftp.redhat.com/pub/contrib/noarch/alien-6.53-3.noarch.rpm
>
> When I try to convert the debian packages to Red Hat packages,
> alien reports errors and doesn't build the rpms:
I have not been able to make the same RPM binary of alien work with my Red
Hat 6.2 box yet, but I haven't spent much time on it. I prefer to avoid
installing alien from a source distribution because it is not clear to me
where all of the files are installed, and this may create update headaches.
> Any ideas what I should try now?
Rudolf has already pointed you to an explanation of how to manually unpack
the .deb packages. Anyway, it may be worth making a few more points (Dan:
you might consider adding this material to your CMU CL HOWTO).
1) The executables of both CMU CL and ACL are called "lisp". So if one is
handed code intended for the other, something interesting may happen. I
have solved the problem by setting the symbolic links:
/usr/local/bin/lisp -> /usr/local/acl5/lisp
/usr/local/bin/cmucl -> /usr/bin/lisp
This works because I have /usr/local/bin before /usr/bin in my path.
2) After manually extracting the .tar.gz archives from the .deb packages, I
collect the list of all files included in the tarballs, e.g.:
tar ztvf data.tar.gz >> cmucl-files.txt
This may come in handy when I decide to upgrade CMU CL, because I know
which files need to be removed.
3) The .deb packages include a number of scripts that are executed during
installation and that get lost if the archive is extracted manually. Before
running CMU CL, be sure to set it so that it can find its main image file.
You can do it manually by setting a symbolic link in /usr/lib/cmucl to the
appropriate image, such as lisp-normal.core. The /usr/sbin/cmuclconfig
script does the same, but if you also have ACL installed, because of 1) the
procedure may fail when handing the config.lisp file to the ACL "lisp"
executable.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
> On 10 Jul 2000 12:35:34 +0200, George Smith <······@rz.uni-potsdam.de>
> wrote:
>
> > I'm trying to get cmucl running on Red Hat 6.0, thus far without success.
> > I've tried the folowing thus far:
> >
> > 1) install the linux binaries from
> > ftp://ftp2.cons.org/pub/languages/lisp/cmucl/release/
> [...]
> > /usr/local/lib/cmucl/bin/lisp: error in loading shared libraries:
> > /usr/local/lib/cmucl/bin/lisp: undefined symbol: __setfpucw
>
> This is a known problem. CMU CL 18b for Linux relies on an undocumented
> feature of glibc 2.0.x that changed in an incompatible way in glibc 2.1.x,
> which is shipped with Red Hat 6.x.
Is there anything wrong with the following workaround? Define the
function __setfpucw() as follows:
#include <fpu_control.h>
void __setfpucw(unsigned int cw) { _FPU_SETCW(cw); }
Then compile that function and put it into its own separate shared
object file, say "set-fpu-hack.so", and run the downloaded CMU CL
binary with the LD_PRELOAD environment variable set to the pathname of
set-fpu-hack.so.
This hack *seems* to work -- well, it doesn't crash anyway -- and it
was easier (for me) than building everything from a Debian package,
but I was wondering if it's really OK. (Currently I just use CMU CL
for toy programs, not for anything important.) If this hack is OK,
then it has the advantage of working with all executables that
reference __setfpucw, not just CMU CL.
I admit, though, that re-building the executable correctly, when
possible, is the Right Way.
"Aaron Gross" <············@bfr.co.il> wrote in message
···················@hecate.bfr.co.il...
> Paolo Amoroso <·······@mclink.it> writes:
<...snippage...>
> This hack *seems* to work -- well, it doesn't crash anyway -- and it
> was easier (for me) than building everything from a Debian package,
> but I was wondering if it's really OK. (Currently I just use CMU CL
> for toy programs, not for anything important.) If this hack is OK,
> then it has the advantage of working with all executables that
> reference __setfpucw, not just CMU CL.
>
> I admit, though, that re-building the executable correctly, when
> possible, is the Right Way.
True, but this hack worked for me (before I switched to Debian).
Larry
George Smith <······@rz.uni-potsdam.de> writes:
> I'm trying to get cmucl running on Red Hat 6.0, thus far without success.
[...]
> When I try to convert the debian packages to Red Hat packages,
> alien reports errors and doesn't build the rpms:
I have never used alien and cannot comment on that, but an entry in
the Debian Faq-O-Matic describes how to get at the contents of a
.deb archive:
http://www.debian.org/fom/54.html
Hopefully, you can install cmucl by hand from that point.
Rudolf Schlatte <········@ist.tu-graz.ac.at> writes:
> George Smith <······@rz.uni-potsdam.de> writes:
>
> > I'm trying to get cmucl running on Red Hat 6.0, thus far without success.
> [...]
> > When I try to convert the debian packages to Red Hat packages,
> > alien reports errors and doesn't build the rpms:
>
> I have never used alien and cannot comment on that, but an entry in
> the Debian Faq-O-Matic describes how to get at the contents of a
> .deb archive:
>
> http://www.debian.org/fom/54.html
>
> Hopefully, you can install cmucl by hand from that point.
Thanks to Rudolf and Christophe for helpful hints and demystification.
For whatever reason, the error messages changed after an upgrade to Alien 7.5
but I still wasn't able to make an rpm.
I was able to use ar to extract data.tar.gz out of the debian package and
then use gunzip and tar to get the actual data. Now I just have to figure
out where I want to put which files. I should be able to figure that out by
comparing the paths in data.tar with my solaris installation and thinking
about how things are normally set up in Red Hat...
Thanks,
George Smith
······@bloomfield.phil1.uni-potsdam.de
Institut fuer Germanistik
Universitaet Potsdam