Hi Frank
Resetting the timestamps of parse.[ch] did nothing to solve the "poisoned malloc/realloc" problem. I eventually reverted to bison 1.75 (from 1.875, which seems to be more hassle than I care for) and the poison issues went away. Now, I get another problem. Just after the RTS configure, when trying to build the RTS, somehow, "-lgpc" gets passed to xgpc. Of course libgpc.a does not exist at this stage, since it is precisely what "make" is trying to build. So the RTS build falls flat with a "cannot find -lgpc" error. This is a new one to me, and I am not sure whether it has anything to do with poisoned bisons or anything else. Something seems to have gone seriously awry here. Any ideas of how "-lgpc" can happen to be passed at this point?
The interesting thing is that the new gcc can bootstrap itself without any problem. Perhaps the MSYS environment (or my hacks of the sources) are introducing some new problems that only show up with GPC?
It seems obvious that the root cause of these problems lies in the gcc-3.2.3 on which I am building. If I try building GPC with the gcc- 2.95.3 MSYS compiler (with just "make"), I succeed without any complaints about poison or any other problem. If I try "make bootstrap", it doesn't succeed, obviously because the intermediate gcc is not able to build GPC, even though it is able to build the core gcc, and it is also able to bootstrap itself if I configure with "--enable-languages=c". The gcc-3.2.3 that is produced by this bootstrap process is also not able to build GPC successfully (at least, it fails at the RTS build) as seen above. Have I given sufficient information for what might be the problem to be discernible?
Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
Resetting the timestamps of parse.[ch] did nothing to solve the "poisoned malloc/realloc" problem. I eventually reverted to bison 1.75 (from 1.875, which seems to be more hassle than I care for) and the poison issues went away. Now, I get another problem. Just after the RTS configure, when trying to build the RTS, somehow, "-lgpc" gets passed to xgpc. Of course libgpc.a does not exist at this stage, since it is precisely what "make" is trying to build. So the RTS build falls flat with a "cannot find -lgpc" error. This is a new one to me, and I am not sure whether it has anything to do with poisoned bisons or anything else.
Certainly not.
Something seems to have gone seriously awry here. Any ideas of how "-lgpc" can happen to be passed at this point?
It doesn't appear anywhere in the makefiles etc. Are you sure you don't pass it yourself in your build scripts, compiler wrappers, environment variables, or anything?
Furthermore, it shouldn't even matter since `-l' options are used only during linking, and the RTS isn't linked (unless perhaps if you try to build a dynamic library which isn't well tested, anyway, and doesn't happed by default). I just tried with RTSFLAGS=-lgpc, and it worked (with warnings about unused linker input file).
What's the make output you get?
The configure test does link some test programs (but with the C compiler only, not with xgpc). If you say it happens after configure, that can't be it, either.
Frank
-
Frank Heckenbach -
Prof. A Olowofoyeku (The African Chief)