Hi Frank/Waldeck
I am trying to build GPC for the MSYS platform. After configuring, "make" is fine in building gcc and gpc. But if I run "make bootstrap" instead, when getting to the parse.y/parse.c stage of gpc, I get errors about attempting to use "poisoned malloc" and "poisoned realloc". I am not sure what any of this is about, or how to solve this problem.
Please advise. Thanks.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
I am trying to build GPC for the MSYS platform. After configuring, "make" is fine in building gcc and gpc. But if I run "make bootstrap" instead, when getting to the parse.y/parse.c stage of gpc, I get errors about attempting to use "poisoned malloc" and "poisoned realloc". I am not sure what any of this is about, or how to solve this problem.
This is one of the mentioned bison version problems. Using the latest CVS bison should help -- if you manage to build it (which is not easy since it requires bleeding edge versions of many other tools). I read that a new release of bison is coming soon, so there's hope ...
Or don't change anything in parse.y and make sure that parse.[ch] are not older than parse.y (which should be the case in the source distribution).
Frank
On 12 Oct 2003 at 17:32, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
I am trying to build GPC for the MSYS platform. After configuring, "make" is fine in building gcc and gpc. But if I run "make bootstrap" instead, when getting to the parse.y/parse.c stage of gpc, I get errors about attempting to use "poisoned malloc" and "poisoned realloc". I am not sure what any of this is about, or how to solve this problem.
This is one of the mentioned bison version problems. Using the latest CVS bison should help -- if you manage to build it (which is not easy since it requires bleeding edge versions of many other tools). I read that a new release of bison is coming soon, so there's hope ...
Ok ...
Or don't change anything in parse.y and make sure that parse.[ch] are not older than parse.y (which should be the case in the source distribution).
As I reported to you in a private email. I have had to make amendments to parse.c and gpc.h (relating to some things in parse.c). So parse.c should be newer than parse.y, and therefore, I shouldn't have got this problem (or is this not the case?).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
Or don't change anything in parse.y and make sure that parse.[ch] are not older than parse.y (which should be the case in the source distribution).
As I reported to you in a private email. I have had to make amendments to parse.c and gpc.h (relating to some things in parse.c). So parse.c should be newer than parse.y, and therefore, I shouldn't have got this problem (or is this not the case?).
If parse.h is also not older -- and if the parse.c that you made your changes to wasn't already rebuilt by your bison (I suspect it was -- you might want to extract it from the distribution and redo your changes).
Frank
Russell Whitaker wrote:
On Sun, 12 Oct 2003, Frank Heckenbach wrote:
[..]
... and make sure that parse.[ch]> are not older than parse.y (which should be the case in the source distribution).
why not "touch -r parse.h parse.* " which makes them the same time?
If parse.c wasn't already rebuilt. (In fact, just `touch parse.[ch]' will also do then.) But if parse.c was rebuild, it's too late. And if significant changes were made to parse.y, they won't take effect when touching parse.[ch], of course.
Frank