Re: [Cvs-test-results] CVS trunk testing results (BSDI BSD/OS)

[Derek Price]

Larry Jones wrote:

>>CVS trunk test results for Sun Sep 18 21:29:01 EDT 2005
>>BSD/OS thor.net.plm.eds.com 4.2 BSDI BSD/OS 4.2 Kernel #5: Thu Jun 16 
>>15:47:12 EDT 2005     address@hidden:/usr/src/sys/compile/THOR  i386
>> 9:29PM  up 19 days,  1:48, 0 user, load averages: 1.55, 1.57, 1.58
>> 
>>Build failed; see /u/scjones/nightlyBSD.log for details
>>    
>>
>
>Looks like the same problem we're having on lots of other systems:     
>
>source='/u/scjones/cvs-nightly/lib/regex.c' object='regex.o' libtool=no  
>DEPDIR=.deps depmode=gcc /bin/bash /u/scjones/cvs-nightly/build-aux/depcomp  
>gcc -DHAVE_CONFIG_H -I. -I/u/scjones/cvs-nightly/lib -I..    -Ino/include  -g 
>-O2 -c /u/scjones/cvs-nightly/lib/regex.c
>gcc: Internal compiler error: program cc1 got fatal signal 11
>*** Error code 1
>  
>

I think it is the combination of the following code from config.h &
regex_internal.h:

#define restrict __restrict

...

#define __restrict restrict


I'm guessing gcc 2.95.4 doesn't handle the infinite loop well.

I spent a little time looking into the code, though, and can't figure
out how both these definitions could be defined at once, so I'm not
certain I have it right, but simply commenting out the restrict
definition mess in regex_internal.h on Mac OS X got things to progress a
bit further, until __restrict wasn't recognized later.  (Mac OS X wasn't
one of the segfaulting systems - I haven't verified yet that the OS X
failures were releated to the others but it still looks like a good
guess - one thing at a time.)

I should be able to spend some more time on this today.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>