Re: [gccsdk] Flex and Bison broken?

In message <DUB120-DS2E5C5C93CC121EC758255F02A0@phx.gbl>
alan buckley <alan_baa@hotmail.com> wrote:


>
> I finally got a chance to try a rebuild of m4 and bison and unfortunately
> both need their autobuilder recipes updated for the latest version/compiler
> so won't build.
>

I've had them 'building' OK with the 4.1.2 cross-compiler, cant remember if all the patches lined up or not, sometimes the target area for patches moves on newer versions.

Reportedly a positive for byacc, where it doesn't get locked into a compiler version to work, so it is possible ther may be gcc version dependency.

> Though having re-read the thread it seems your initial problem was with
> Make. Have you solved this with the variables you have found? Or does
> Make need to look for things on RISC OS in a more intelligent way?
>
Dont think there was any make related problems.
Will initially was baffled by the paths that bison was using to find the pkgdatafiles and the m4 binary, but these can be set in the environment.

> Have you some simple Makefile(s) and other source files for the other
> tools so I can try them out and see what is happening myself?
>
Other tools? are you talking about byacc, reflex alternatives.
There is nothing much to see though, they just compile and work.
This is a solution for when bison is used as yacc, but I imagine no good for source code that includes m4 macros that get used.

> I've never used m4, flex or bison in any details, but a few simple
> examples that show what isn't working would help.
>
> Regards,
> Alan

Part of Bison source, there is examples, but any useage will show the problems.
Though the error is not explicit, I believe the issue is with subpipe/exec arrangement not getting the environment or arguments to m4 properly, and I dont think it gets anything sensible back from m4 either.

My approach to this problem is to merge the gnu m4 source into the gnu bison source, changing names in a few cases (symtab.c to m4symtab.c, output.c to m4output.c) and I'm hoping by renaming the m4 main( to m4main( that I can change the use of exec m4 to an internal function.
The two sources are very similar, there is one conflict with rpl_malloc, but it is not needed by the m4 side once the original configuration is done.
So I remarked it out of the combined config.h
Reconfiguring would be a problem.

I have the combined binary/libs building OK, it just needs the work done to call the m4main function through the subpipe/fork arrangement. It will be down to wether fork or vfork can meet the demand I think.

I dont mind being made to look foolish if you can get bison/m4 to work the normal way though (-:

Ron M.



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK