Subject: Problems building clisp-1999-01-08 on linux-2.2.1, glibc-2.1

From: Russell Senior <[email-masked]>
Date: 18 Mar 1999 23:00:57 -0800

I have tried building from source using both gcc-2.8.1 and egcs-1.1.2.

Both (these examples are from the egcs build attempt) fail in the same
place during make:

   /packages/development/egcs/bin/gcc -O -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DDYNAMIC_FFI -c foreign.c
   In file included from foreign.d:5:
   lispbibl.d:7314: warning: register used for two global register variables
   foreign.d: In function `foreign_layout':
   foreign.d:634: `sint64' undeclared (first use in this function)
   foreign.d:634: (Each undeclared identifier is reported only once
   foreign.d:634: for each function it appears in.)
   foreign.d:634: parse error before `sint64'
   foreign.d:634: warning: no semicolon at end of struct or union
   foreign.d:635: `uint64' undeclared (first use in this function)
   foreign.d:645: parse error before `uint64'
   foreign.d:645: warning: no semicolon at end of struct or union
   foreign.d: In function `convert_from_foreign':
   foreign.d:953: `sint64' undeclared (first use in this function)
   foreign.d:953: parse error before `val'
   foreign.d:955: `val' undeclared (first use in this function)
   foreign.d:967: `uint64' undeclared (first use in this function)
   foreign.d:967: parse error before `val'
   foreign.d: In function `convert_to_foreign':
   foreign.d:1663: `sint64' undeclared (first use in this function)
   foreign.d:1663: parse error before `val'
   foreign.d:1665: `val' undeclared (first use in this function)
   foreign.d:1674: `uint64' undeclared (first use in this function)
   foreign.d:1674: parse error before `val'
   foreign.d: In function `do_va_start':
   foreign.d:3099: warning: left-hand operand of comma expression has no effect
   foreign.d:3101: warning: left-hand operand of comma expression has no effect
   make: *** [foreign.o] Error 1
   russell@dalles[/build/clisp] $ 

I am also seeing lots of warnings of the form:

   /packages/development/egcs/bin/gcc -O -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DDYNAMIC_FFI -c spvw.c
   In file included from spvw.d:21:
   lispbibl.d:7314: warning: register used for two global register variables
   spvw.d: In function `main':
   spvw.d:1778: warning: variable `argv_memneed' might be clobbered by `longjmp' or `vfork'

Any ideas on what's going wrong here?

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 19 Mar 1999 09:32:20 -0500

>>>> In message <[email-masked]>
>>>> On the subject of "Re: Problems building clisp-1999-01-08 on linux-2.2.1, glibc-2.1"
>>>> Sent on Fri, 19 Mar 1999 00:03:44 -0800 (PST)
>>>> Honorable Russell Senior <[email-masked]> writes:

I've never seen this.
Please indicate what sources you are using (release, snapshot), as well
as the configure command you issued.

 >> Any ideas on what's going wrong here?

this is okay.

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Don't use force -- get a bigger hammer.

---

From: Russell Senior <[email-masked]>
Date: 19 Mar 1999 07:42:03 -0800

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

Sam> I've never seen this.  Please indicate what sources you are using
Sam> (release, snapshot), as well as the configure command you issued.

Sorry.  It is the clisp-1999-01-08 release.

I configured from a build directory with a pretty plain-jane:

  /src/clisp-1999-01-08/configure --srcdir=/src/clisp-1999-01-08 --prefix=/packages/development/lisp/clisp

then followed the supplied directions on makemake and config.lsp.
The error occurred during the `make' step.

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 19 Mar 1999 11:21:29 -0500

>>>> In message <[email-masked]>
>>>> Sent on Fri, 19 Mar 1999 07:45:42 -0800 (PST)

this is fairly strange.
I have a similar system (egcs 1.1.1, glibc 2.1) and I do not see this.
where did you get the source tree? (cellar.goems.com? cons.org?)
Not that it should matter... :-)
If you do not insist on compiling yourself, you can find glib2.1 binary
RPMs on ftp://cellar.goems.com/pub/clisp.
If you do insist on compiling yourself, you might try to edit foreign.d
and replacing the offending symbols which whatever is defined on your system.

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
The world is coming to an end.  Please log off.

---

From: Russell Senior <[email-masked]>
Date: 19 Mar 1999 09:55:16 -0800

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

Sam> this is fairly strange.  I have a similar system (egcs 1.1.1,
Sam> glibc 2.1) and I do not see this.  where did you get the source
Sam> tree? (cellar.goems.com? cons.org?)  Not that it should
Sam> matter... :-)

I got it (1999-01-08) originally from cons.org back in early February.

   $ md5sum clispsrc.tar.gz 
   2faa2d691742f2ab4d259c51fe1afaf5  clispsrc.tar.gz

Sam> [...] If you do not insist on compiling yourself, you can find glib2.1
Sam> binary RPMs on ftp://cellar.goems.com/pub/clisp.  If you do
Sam> insist on compiling yourself, you might try to edit foreign.d and
Sam> replacing the offending symbols which whatever is defined on your
Sam> system.

I prefer building from source.  I'll investigate.  I am also going to
try the 1999-03-19 version from cellar.goems.com and see how that
goes.

Thanks.

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 19 Mar 1999 13:43:36 -0500

>>>> In message <[email-masked]>
>>>> Sent on Fri, 19 Mar 1999 10:00:13 -0800 (PST)
 >> I prefer building from source.  I'll investigate.  I am also going
 >> to try the 1999-03-19 version from cellar.goems.com and see how that
 >> goes.

please beware - this is a snapshot: it might not compile either!
[it includes UNICODE support though]

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Those who can laugh at themselves will never cease to be amused.

---

From: Russell Senior <[email-masked]>
Date: 23 Mar 1999 23:41:34 -0800

Russell> I prefer building from source.  I'll investigate.

Under linux-2.2.4 using both gcc-2.8.1 and egcs-1.1.2 and glibc-2.1,
building clisp-1999-01-08 from source succeeded after making the
following change:

diff -r -u clisp-1999-01-08/src/unix.d clisp-1999-01-08-munged/src/unix.d
--- clisp-1999-01-08/src/unix.d Thu Jan  7 08:33:51 1999
+++ clisp-1999-01-08-munged/src/unix.d  Tue Mar 23 21:22:15 1999
@@ -845,7 +845,7 @@
     extern_C void* dlopen (const char * library, int flag);
     extern_C void* dlsym (void* handle, DLSYM_CONST char * symbol);
     extern_C int dlclose (void* handle);
-    extern_C DLERROR_CONST char * dlerror (void);
+#    extern_C DLERROR_CONST char * dlerror (void);
     #define HAVE_DYNLOAD
   #endif
 
I observed some mystery segfaults during the builds which seemed to go
away when I reran make, giving the appearance of a possible
intermittent hardware (thermal?) problem with my box.  This might
explain some of the problems I saw earlier, so I can't say with any
confidence that the new linux kernel had any influence on this
evenings success.

Also, in my local version I have modified src/lisparit.d to use
'DOUBLE-FLOAT instead of 'SINGLE-FLOAT for *DEFAULT-FLOAT-FORMAT* and
*READ-DEFAULT-FLOAT-FORMAT*.  This causes the `make check' to fail
several tests, apparently innocously (`make check' succeeded before
this change).  Perhaps if the tests rely on these values being
'SINGLE-FLOAT they should be set explicitly in tests.lsp?

-- 
Russell Senior
[email-masked]

---

From: Russell Senior <[email-masked]>
Date: 24 Mar 1999 02:12:16 -0800

Linux-2.2.4, gcc-2.8.1, glibc-2.1.

When configuring with a --prefix=foo option, the specified directory
`foo' is not automatically created with `make install'.  I don't know
precisely how this is dealt with in other packages.

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 24 Mar 1999 09:10:21 -0500

>>>> In message <[email-masked]>
>>>> Sent on Tue, 23 Mar 1999 23:47:21 -0800 (PST)

yep.
I am getting this with the current CVS tree.
I hope this will be fixed in the next release.

 >> I observed some mystery segfaults during the builds which seemed to
 >> go away when I reran make, giving the appearance of a possible

yep.
I am getting these too ("... indicative of gcc bug &c")
they go away on a second or third attempt.

 >> 'DOUBLE-FLOAT instead of 'SINGLE-FLOAT for *DEFAULT-FLOAT-FORMAT*
 >> and *READ-DEFAULT-FLOAT-FORMAT*.  This causes the `make check' to
 >> fail several tests, apparently innocously (`make check' succeeded
 >> before this change).  Perhaps if the tests rely on these values
 >> being 'SINGLE-FLOAT they should be set explicitly in tests.lsp?

no-no-no!!!
HyperSpec/Body/var_stread-de_oat-formatst.html
If you want a different value for these variables, set them in ~/.clisrc
or dump you own memory image (like I do).

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
A man paints with his brains and not with his hands.

---

From: Sam Steingold <[email-masked]>
Date: 24 Mar 1999 09:21:09 -0500

>>>> In message <[email-masked]>
>>>> On the subject of "clisp-1999-01-08 install buglet"
>>>> Sent on Wed, 24 Mar 1999 02:15:53 -0800 (PST)

first, you shouldn't do something like this.
second, it's not hard to fix it: just call mkdir -p instead of just
mkdir.
third, I am not sure that all mkdir implementations support -p, so I
will wait for Bruno to come back from his vacation before committing
this. 

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
.sigs are like your face - rarely seen by you and uglier than you think

---

From: Russell Senior <[email-masked]>
Date: 25 Mar 1999 10:58:06 -0800

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

Russell> I observed some mystery segfaults during the builds which
Russell> seemed to go away when I reran make, giving the appearance of
Russell> a possible intermittent hardware (thermal?) problem with my
Russell> box.  This might explain some of the problems I saw earlier,
Russell> so I can't say with any confidence that the new linux kernel
Russell> had any influence on this evenings success.

Sam> yep.  I am getting these too ("... indicative of gcc bug &c")
Sam> they go away on a second or third attempt.

New information implies that it might be a linux kernel problem.  The
errors I was seeing were signal 9 (KILL) processes deaths apparently
resulting from memory management issues in the kernel.  With
linux-2.2.4, I am now seeing these problems primarily during the
configuration stage, and not during the compile.  I suspect this is
what caused my earlier problems with the long long: confusion from
abnormally terminated autoconf tests.

-- 
Russell Senior
[email-masked]

---

From: Russell Senior <[email-masked]>
Date: 25 Mar 1999 11:16:15 -0800

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

Russell> Linux-2.2.4, gcc-2.8.1, glibc-2.1.

Russell> When configuring with a --prefix=foo option, the specified
Russell> directory `foo' is not automatically created with `make
Russell> install'.  I don't know precisely how this is dealt with in
Russell> other packages.

Sam> first, you shouldn't do something like this.  

Why not?  I find it quite useful.

Sam> second, it's not hard to fix it: just call mkdir -p instead of
Sam> just mkdir.

Sam> third, I am not sure that all mkdir implementations support -p,
Sam> so I will wait for Bruno to come back from his vacation before
Sam> committing this.

Automake seems to provide a script called mkinstalldirs for
automake'd/autoconf'd packages, which I expect resolves many
portability issues.  

I believe I have seen the mkdir -p option used elsewhere.

-- 
Russell Senior
[email-masked]

---

From: Sam Steingold <[email-masked]>
Date: 25 Mar 1999 14:44:38 -0500

>>>> In message <[email-masked]>
>>>> Sent on Thu, 25 Mar 1999 11:02:54 -0800 (PST)
 >> New information implies that it might be a linux kernel problem.
 >> The errors I was seeing were signal 9 (KILL) processes deaths

yeah, I seem to recall something like this...

 >> apparently resulting from memory management issues in the kernel.
 >> With linux-2.2.4, I am now seeing these problems primarily during
 >> the configuration stage, and not during the compile.  I suspect this
 >> is what caused my earlier problems with the long long: confusion
 >> from abnormally terminated autoconf tests.

hmmm - can you send a meaningful bug report to Linus?
(I cannot!)

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
You think Oedipus had a problem -- Adam was Eve's mother.

---

From: Sam Steingold <[email-masked]>
Date: 25 Mar 1999 15:10:50 -0500

>>>> In message <[email-masked]>
>>>> On the subject of "Re: clisp-1999-01-08 install buglet"
>>>> Sent on Thu, 25 Mar 1999 11:19:06 -0800 (PST)

how useful can is be - creating a top level directory just for one
package?  if you do that, why install at all?  clisp can run in-place
just fine.

 >> automake'd/autoconf'd packages, which I expect resolves many

oh come on - you cannot expect *everyone* to install automake, can you?
or do you want mkinstalldirs to be distributed with clisp?

-- 
Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux
Micros**t is not the answer.  Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
When we write programs that "learn", it turns out we do and they don't.

---

From: Russell Senior <[email-masked]>
Date: 25 Mar 1999 12:36:08 -0800

>>>>> "Sam" == Sam Steingold <[email-masked]> writes:

Sam> hmmm - can you send a meaningful bug report to Linus?

I have been testing a few things for him and supplying my results.  I
haven't heard anything definitive back yet.  Curiously, I am only
seeing the `Out of memory for <foo>' (where <foo> is usually cc1, but
sometimes sed, sh, etc) syslog messages during a CLISP configure.  I
configured/compiled gcc and the kernel several times yesterday and
didn't see any there.  Apparently, the CLISP configure is doing some
magical spock-nerve-pinch on the kernel.

-- 
Russell Senior
[email-masked]

---

From: Russell Senior <[email-masked]>
Date: 25 Mar 1999 13:02:39 -0800

Russell> Why not?  I find it quite useful.

Sam> how useful can is be - creating a top level directory just for
Sam> one package?  if you do that, why install at all?  clisp can run
Sam> in-place just fine.

It is useful for installing multiple versions, and for later
uninstalling (rm -rf foo).  In contrast, running in place retains the
original source and build by-products, which otherwise could be easily
removed.

Russell> Automake seems to provide a script called mkinstalldirs for
Russell> automake'd/autoconf'd packages, which I expect resolves many
Russell> portability issues.

Sam> oh come on - you cannot expect *everyone* to install automake,
Sam> can you?  or do you want mkinstalldirs to be distributed with
Sam> clisp?

Automake (I think it is) provides a `make dist' target which builds a
distribution tarball.  The script is included in the tarball.  In
CLISP's case, the mkinstalldirs script could perhaps be distributed
with the package and the Makefiles adapted to use it.

-- 
Russell Senior
[email-masked]