[haiku-development] Re: Buildbot woes of gcc2 (on FreeBSD)
- From: "Ingo Weinhold" <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 06 Nov 2011 18:33:27 +0100
Matt Madia wrote:
> Hello from home!
Good to hear you made back despite running low on caffeine. ;-)
> As mentioned on Adrien's BeGeistert 024 report[1], I've been working
> on getting Buildbot set up (instead of trying to wrench Build-O-Matic
> into supporting git ). As a bonus, we'll be getting lots of awesome
> features that are built into Buildbot. (buildbot.net)
>
> Unfortunately, it hasn't been as easy as cream pie. One of GCC 2's
> build tools, `fixinc` / `fixincl` causes Buildbot to never realize the
> build has completed successfully. From what Oliver and I found out,
> fixinc will spawn a shell process, opens some pipes (or file
> descriptors) for communication, the calling process will crash,
> forcing the child to become its own process group and keep that pipe
> open. Build log output: http://pastebin.com/CfmXr42U (search for
> "*** barf *** barf ***" to see where the trouble starts)
>
> That is why Buildbot never acknowledges the gcc2 buildtools to be
> completed successfully.
I think the easiest solutions would be to disable the fixincludes target in
gcc's Makefile (respectively Makefile.in). What fixincludes does is scan the
target system's (i.e. Haiku's) standard C headers for compliance issues and
produce fixed versions of affected headers. Those fixed headers then live in a
directory in gcc's installation and override the system headers when something
is compiled. While that approach has a point, it also has the serious drawback
that whenever changing the Haiku headers gcc would have to be rebuilt as well,
or the old fixed headers would shadow the newly changed headers and thus the
changes wouldn't be visible when compiling. Years ago I analyzed which headers
are actually affected and adjusted our headers accordingly. Now fixincludes
only generates one "fixed" header, math.h which it does unconditionally. As can
be seen in build_cross_tools we forcibly remove that "fixed" header (that
reminds me that we probably don't do that when building a n
ative compiler). Long story short, for our purposes the fixincludes pass is a
no-op and disabling it in gcc shouldn't have any negative side effect. I
haven't check how easy it is to do that, though, but probably not too
complicated.
> With Urias's help, we've been testing building gcc2 on linux mint, but
> that seems to run into its own issues[2]. Oddly, if he runs the build
> as a normal person would, it builds successfully. :|
Just from the error code I would guess that it's an incompatiblity of the old
grammar file (parse.y) with a newer bison version. This kind of problem -- i.e.
the sources being so old that newer tools become incompatible -- is something
we've seen in various incarnations already and I'm afraid it isn't going to be
better. That the manual build succeeds while the buildbot one doesn't, is
probably only a coincidence. Assuming you used different checkouts, the order
in which the files in the concerned directory had been checked out is relevant.
parse.c and parse.h are generated from parse.y, but they are still in the
repository. If parse.c/h have a newer modified date than parse.y, make probably
won't try to regenerated them, otherwise it will, resulting in bison to be run
and fail in one instance, while not being run in the other. So, a possible
solution would be to just touch parse.c/h before running the build. An
alternative would be to try an older bison version.
CU, Ingo
Other related posts:
