This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: There is no consensus on beos yet...





> 
>   > When fixincludes *does* run (IE after killing the right processes, etc 
>   > necessary to make it go all the way through), it makes more changes than it
>   > used to, on the same headers. Those changes cause the headers to no longer 
>   > work properly.
> Then that's a bug in fixinc that needs to be fixed (changing a header in such
> a way as to cause it to not work properly).
> 
>   > It used to make 0 changes to the same headers, leading me to believe that 
>   > our headers aren't broken.
> That's not proof that the headers are correct -- it's merely a datapoint that
> says at some time in the past your headers were believed correct.  BUt that
> doesn't mean they actually are.  
> 
> As GCC/G++ development continues we often find subtle problems in header files
> that have gone unnoticed for years.  We install changes to fixinc to deal with
> such problems, but if you've disabled fixinc, then your system (if it has
> such problems) will not get fixed.  This is *precisely* what has happened in
> the past for systems which disabled fixincludes.  
> 
> Disabling fixincludes is bad.    Don't do it.
> 

Except that fixinc doesn't run properly on the platform, and this is not 
going to change, unless fixinc works the way it used to.

"AutoGen-erated Fixincludes is believed to work on nearly every UNIX box
on the planet. However, if you should discover a flavor of
UNIX on which it does not work, please email Bruce Korb the details. We 
want to fix it. "
BeOS is one of the ones that is an exception.

It's not that i don't want fixincludes to run on BeOS, i'd happily fix 
the headers problem in fixincludes, if fixincludes ran properly. However, 
it doesn't.

Since it's autogen'ed, i grabbed autogen to see if i could figure out 
what was up.

Same error there you get after the *first* hang
:  gcc -g -O2 -o getdefs 
-static getdefs.o opts.o
../autoopts/.libs/libopts.a top_builddir=.. \ ../src/autogen -Taginfo
-bgetdefs \
        -L ../autoopts -DLEVEL=section \
        ../getdefs/opts.def Closing server:  Alarm signal (14) received
Last command issued:  \cd /boot/home/Downloads/autogen-4.5.12/getdefs echo
getdefs.texi | sed 's/texi$/menu/' echo echo
ShElL-OuTpUt-HaS-bEeN-cOmPlEtEd CLOSING SHELL SERVER - command failure: 
        echo getdefs.texi | sed 's/texi$/menu/'
                                                      
<hang>

However, the first hang for BeOS is like this:

(cut and paste killed the newlines, though they aren't relevantfor the hang)
Fixing headers into /boot/home/egcs/build/gcc/include for i586-pc-beos
target Finding directories and links to directories
 Searching /boot/develop/headers/posix/.  Making symbolic directory links
Fixing directory /boot/develop/headers/posix into
/boot/home/egcs/build/gcc/include Applying limits_ifndefs to limits.h
Applying sun_malloc to malloc.h Applying hpux8_bogus_inlines to math.h
Applying math_exception to math.h Applying math_huge_val_ifndef to math.h
Fixed:  math.h
/bin/sh: d: command not found     

You then need to kill off the sh that fixincl spawned, that is sitting
waiting to read from a pipe: 
  70458                   sh  sem  10      14      35 piperd(687829)   

which gives you:  NOTE: server restarted 
CLOSING SHELL SERVER - command failure: 
        file=regex.h 
if ( test -r reg_types.h ) > /dev/null 2>&1 then echo
TRUE else echo FALSE fi Script yielded bogus result of `':  file=regex.h
if ( test -r reg_types.h ) > /dev/null 2>&1 then echo TRUE else echo FALSE
fi Applying gnu_types to stddef.h Fixed:  stddef.h Applying stdio_stdarg_h
to stdio.h Applying stdio_va_list to stdio.h Fixed:  stdio.h Applying
sysv68_string to string.h
NOTE: server restarted               

<it then crashes fixincl>
<then the sh process hangs on pipe read again, after you clear the crash>
Then you kill fixincl, and it terminates, and everything else goes about 
it's way.


I spent a long time debugging fixincludes, and all i could get is that 
the problem lies in the way it forks, and expects to make stdout become 
the new stdin.


--Dan

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]