Re: [Gcl-devel] _BOOL problem in GCL 2.4.3 for GCC 2.96

[Camm Maguire]

Greetings!

root <address@hidden> writes:

> Camm,
> 
> This patch will fix 2.4.3 to work on all systems.
> You can just save this mail file to 386-linux.defs.patch and type:
>    cd gcl-2.4.3/o
>    patch < 386-linux.defs.patch 
> Perhaps you could call it 2.4.4?
> 
> The problem is the include of the file
> /usr/lib/gcc-lib/i386-redhat-linux/2.96/include/stdbool.h
> which typedefs bool. This causes sfasl.c to fail to compile.
> 
> To fix the build on GCC 2.96 add the flag -D_STDBOOL_H to the
> sfasl.h compile line. The correct way to do this is to apply
> the attached patch file. Note that configure writes over several
> files so you can't patch them directly. Under Bill's scheme you
> make platform specific changes in the h/*.defs files.
> 
> The "bug" was introduced when bfd support was added.
> In this particular case the "include <bfd.h>" also does an
> "include <stdbool.h>" which typedefs bool causing the conflict.
> If you read the include <bfd.h> file you'll find that this bug
> has bitten many people. There are checks in the file so that
> <stdbool.h> is only included if the compiler version is 2
> and the subversion > 95. Since my RedHat 7.2 is gcc 2.95 this
> works. My RedHat 7.3 is gcc 2.96 and fails. The correct fix
> is NEVER to include this file as it will always cause a conflict
> for GCL. The easiest way to do this is to claim that the file
> has already been included. The first time it is included it
> defines a flag _STDBOOL_H. So, we lie about it and always
> define the flag thus avoiding the problem. 
> 

Thanks for the detailed analysis!  We had dealt with this in CVS with
an #undef bool in object.h, but I rather like your solution better.

BTW, a word to the wise, gcc 2.96 is very broken, and should be
avoided at all costs.  The Gcc people never released it, but the
Redhat people rushed it out as they needed some c++ stuff for a
release they could not reschedule.

I'll try to get a 2.4.4 out this weekend, with a bool fix, and with
the version numbers correctly reported.  If anyone has something else
they think should go in, please let me know by Friday evening.

> Some day I should sign up as a GCL developer :-)
> 

Indeed!!  Whenever you are free and interested ...

Take care,

> Tim
> 
> ===================================================================
> --- 386-linux.defs    Sun Feb  3 13:44:07 2002
> +++ /tmp/386-linux.defs       Wed Nov 20 21:21:08 2002
> @@ -21,7 +21,7 @@
>  # and also in the compiler::*cc* variable for later compilation of
>  # lisp files.
>  # (the -pipe is just since our file system is slow..)
> -CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o 
> -fsigned-char
> +CC = ${GCC} -pipe -fwritable-strings  -DVOL=volatile -I$(GCLDIR)/o 
> -fsigned-char -D_STDBOOL_H 
>  
>  # under redhat 6.1 and slackware 7.0 we needed to have this
>  # link be static, but should be ok with the fix to unixport/rsym_elf.c
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah