This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: There is no consensus on beos yet...
- To: law at redhat dot com
- Subject: Re: There is no consensus on beos yet...
- From: Daniel Berlin <dberlin at cygnus dot com>
- Date: Thu, 16 Nov 2000 11:19:47 -0800 (PST)
- cc: Bruce Korb <bkorb at sco dot COM>, jason at gcc dot gnu dot org, GCC Patches <gcc-patches at gcc dot gnu dot org>
>
> > 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