Subject: [clisp-list] can't build CVS clisp under OpenBSD 3.0 for x86

From: William Harold Newman <[email-masked]>
Date: Wed May 29 11:48:05 2002

The first problem can be fixed (crudely, obviously) by this patch:
Index: src/unitypes.h
===================================================================
RCS file: /cvsroot/clisp/clisp/src/unitypes.h,v
retrieving revision 1.1
diff -u -r1.1 unitypes.h
--- src/unitypes.h      27 May 2002 17:22:43 -0000      1.1
+++ src/unitypes.h      29 May 2002 18:41:17 -0000
@@ -20,7 +20,15 @@
 #define _UNITYPES_H
 
 /* Get uint8_t, uint16_t, uint32_t.  */
+#ifndef __OpenBSD__
 #include <stdint.h>
+#else
+# ifdef __i386__
+#  include <i386/types.h>
+# else
+#  error need uint8_t and friends, do not know where they are for this system
+# endif
+#endif
 
 /* Type representing a Unicode character.  */
 typedef uint32_t ucs4_t;

The second problem is that CLISP's stdbool.h uses #define to turn
"true" and "false" into "1" and "0", and then CLISP elsewhere 
#include's the OpenBSD file "/usr/include/stdbool.h", which does
  /* `_Bool' type must promote to `int' or `unsigned int'. */
  typedef enum {
          false = 0,
          true = 1
  } _Bool;
So then of course when this is preprocessed into
  /* `_Bool' type must promote to `int' or `unsigned int'. */
  typedef enum {
          0 = 0,
          1 = 1
  } _Bool;
gcc is not happy.

I ground to a halt on the second problem, so I dunno whether there's
a third problem.

-- 
William Harold Newman <[email-masked]>
15:11:49 <pmai> It's a law of nature.  The so-called newman constant.
  -- <http://tunes.org/~nef/logs/lisp/02.05.16>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

---

From: Sam Steingold <[email-masked]>
Date: Wed May 29 13:29:03 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] can't build CVS clisp under OpenBSD 3.0 for x86"
> * Sent on Wed, 29 May 2002 13:45:11 -0500
> * Honorable William Harold Newman <[email-masked]> writes:
>

CLISP is not supposed to include "/usr/include/stdbool.h" - it comes
with its own.

--- lispbibl.d	29 May 2002 12:25:19 -0000	1.258
+++ lispbibl.d	29 May 2002 20:27:53 -0000
@@ -1145,7 +1145,11 @@
 #endif
 
 # boolean values:
+#ifdef HAVE_STDBOOL_H
+  #include <stdbool.h>
+#else
 #include "stdbool.h"
+#endif
 
 # Type for signed values, results of comparisons, tertiary enums
 # with values +1, 0, -1

does this help?

> I ground to a halt on the second problem, so I dunno whether there's

I am sure there is - the sources have changed a lot in the recent days.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
When we write programs that "learn", it turns out we do and they don't.

---

From: William Harold Newman <[email-masked]>
Date: Wed May 29 14:16:01 2002

> +++ lispbibl.d	29 May 2002 20:27:53 -0000

Yes, that makes compilation of lispbibl.d succeed.

> I am sure there is - the sources have changed a lot in the recent days.

Some kind of change seems to be needed in order to make uniname.c
compile, too.

gcc -I/usr/local/include -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -c charstrg.c
In file included from uniname.c:27,
                 from charstrg.d:1316:
/usr/include/stdbool.h:18: warning: `false' redefined
stdbool.h:43: warning: this is the location of the previous definition
/usr/include/stdbool.h:19: warning: `true' redefined
stdbool.h:44: warning: this is the location of the previous definition
In file included from charstrg.d:5:
lispbibl.d:7181: warning: register used for two global register variables
In file included from uniname.c:27,
                 from charstrg.d:1316:
/usr/include/stdbool.h:13: syntax error before `0'
/usr/include/stdbool.h:15: warning: redefinition of `_Bool'
stdbool.h:35: warning: `_Bool' previously declared here
*** Error code 1

It's not obvious to me why "./stdbool.h" is getting included here,
since the remaining #include's of stdbool.h, including the one in
uniname.c, refer to <stdbool.h>. Maybe something about the
preprocessing sequence here is causing the #include in lispbibl.d to
be cpp'ed in a context where HAVE_STDBOOL_H isn't defined?

---

From: Sam Steingold <[email-masked]>
Date: Wed May 29 14:59:02 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] can't build CVS clisp under OpenBSD 3.0 for x86"
> * Sent on Wed, 29 May 2002 16:12:19 -0500

maybe you could try removing "./stdbool.h" and looking where the
"include: file not found" error is signaled?
you could also try "gcc -E -dM" to see what macros are defined.

I hope Bruno will weigh in on the issue...

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Even Windows doesn't suck, when you use Common Lisp

---

From: Arseny Slobodjuck <[email-masked]>
Date: Wed May 29 17:26:02 2002

Hello Sam,

Thursday, May 30, 2002, 6:28:19 AM, you wrote:

Sam> CLISP is not supposed to include "/usr/include/stdbool.h" - it comes
Sam> with its own.

These patches was required to build on windows (#include "" instead of
#include <>). But I don't know how it affects unix build, I suppose clisp
won't build on unix with these patches.

-- 
Best regards,
 Arseny                            mailto:[email-masked]