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)