*BSD News Article 8387


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: [386bsd] gcc-2.3.1 and XFree86-1.1 compile
Message-ID: <1992Dec1.153305.15456@runx.oz.au>
Organization: RUNX Un*x Timeshare.  Sydney, Australia.
References: <veit.723126991@du9ds3>
Date: Tue, 1 Dec 92 15:33:05 GMT
Lines: 57

In article <veit.723126991@du9ds3> veit@du9ds3.uni-duisburg.de writes:
>I yesterday managed to compile the XFree86 tree with gcc-2.3.1 (I today
>heard the 2.3.2 is out, but I think this doesn't make much difference).

I built 2.3.2 for Minix.  The differences are minor.

>FYI: There were two minor problems, which I do not know of whether they have
>been corrected in the new gcc version:
>
>1. Don't make the mistake to try run fix-includes on the 386bsd include files,
>   they produce garbage. The includes already provided with 386bsd work
>   fine enough.

For Minix I find it is best to delete all of the gcc headers except two
related to <limits.h>.  This works because

1. the Minix Standard C headers are 99% or better ANSI conformant
2. the machine-dependent types like size_t and ptrdiff_t are already
   specified in the gcc config files to match the ones in the system
   headers
3. varargs stuff for the 386 is simple (at least in 2.3.2 and previous
   versions)

and it is necessary because the system headers use nonstandard methods to
make the declarations of things like size_t unique and to use the right
type for va_list in <stdio.h> (there's no standard).

The same arguments apply to 386BSD, except the 386BSD headers are less
conformant.  Only <assert.h> deserves complete replacement.

gcc-2 attempts to support 386BSD using additional branches in twisty
#ifdef mazes in <stddef.h>, <stdlib.h>, <stdarg.h> and <varargs.h>.  I
hate this approach.  It was botched in 2.3.1.  It is done better for
2.3.2, but there are still strange identifiers like ____386BSD____
(from excessive zeal in fixincludes?).

gcc-2 handles <limits.h> much better using system-independent methods.
It has to, because there are a lot of system-dependent POSIX_THINGIES
defined in <limits.h>.

>2. Many X applications fail compile with 
>   _eprintf: abort() undefined reference
>
>   This is because of a loop in heritance of library functions:
>   The gcc driver links applications with
>
>   gcc -o a.out *.o -l(other libraries) -lgcc -lc -lgcc
>
>   _eprintf is the gcc-2.3.1 builtin for the assert macro, which calls
>    abort internally, which is in libc.a.

This problem could be avoided by deleting the gnu <assert.h>.  Then
_eprintf would not be referenced.  Unfortunately the 386BSD <assert.h>
is not ANSI conformant (assert() is statement but it is supposed to be
an expression).
-- 
Bruce Evans  (bde@runx.oz.au)