Ron wrote on Monday, February 16, 2015 10:19 PM:

In message <dub120-w387dd353c097bcd506734ef0...@phx.gbl>
         alan buckley <alan_...@hotmail.com> wrote:

> WPB wrote on Date: Sat, 7 Feb 2015 20:27:31:
> > Guess what? I'm back!
> >
> > So, now with everyone's help (thank you), I've progressed to the point
> > that 'make' is trying to invoke flex and then bison.
> >
> > Both fail. Flex with the following error:
> >
> > File '$.usr.local.bin.m4' not found
> >
> > I know there is a port of 'm4' at riscos.info, but it's certainly not
> > going to be found at that location on my hard drive! From my limited
> > experience of Linux, that looks like a Linux path converted to a RISC > > OS > > path. I get the same error when trying a very simple invocation of > > 'flex' > > from the command line. Would people agree that 'flex' is broken, or am > > I
> > doing something wrong?
> >
> > So, I plugged in Rik Griffin's port of 'flex'
> > (http://homepage.ntlworld.com/rik.griffin/) and if I change the paths
> > appropriately (because it's a Norcroft-compiled version, so has no > > sfix
> > swapping implemented) I can get it to work.
> >
> > Then we get to Bison, which fails similarly:
> >
> > bison -t -v -b parser -d -o OBJECTS/parser.tab.c src/parser.y
> > src/parser.y:93.17-24: warning: symbol OPERATOR redeclared
> > src/parser.y:94.15-23: warning: symbol MACROTEXT redeclared
> > src/parser.y:263.1: warning: a ';' might be needed at the end of > > action
> > code
> > src/parser.y:263.1: future versions of Bison will not add the ';'
> > src/parser.y:275.1: warning: a ';' might be needed at the end of > > action
> > code
> > src/parser.y:275.1: future versions of Bison will not add the ';'
> > src/parser.y:522.1: warning: a ';' might be needed at the end of > > action
> > code
> > src/parser.y:522.1: future versions of Bison will not add the ';'
> > /HostFS::HostFS.$/AppsInUse/Dev/GCC474r1/!GCC/bin/bison:
> > /home/alanb/gccsdk/env/share/bison/m4sugar/m4sugar.m4: cannot open: No
> > such file or directory
> > make: *** [OBJECTS/parser.tab.c] Error 1
> >
> > So it looks like there's a hard-coded reference in there to a file:
> > /home/alanb/gccsdk/env/share/bison/m4sugar/m4sugar.m4 - again, it > > appears
> > 'bison' is broken. Would people agree?
> >
> > If anyone has any input on this, it would be greatly appreciated.
> >
>
> The path looks like it's from my machine when I last ran the autobuilder
> on bison. If anyone knows what the paths should be for RISC OS (or
> better still had a patch) I can look at fixing and rebuilding both flex
> and bison.
>

I posted elsewhere that the BISON_PKGDATADIR and M4 environment variables can be used. However I've found that though m4 will compile and work on it's own happily,
Bison has a complex subpipe system to use m4 as a filter.
Flex is failing for similar reasons I think.

The Berkely YACC compiles easily (and works), is available from Debian, and reportedly the best YACC available. There are a few 'tricks' that > Bison can do, but wether these will be missed remains to be seen, Bison/M4 is very long winded compared to byacc which is self contained > > and only uses temp files. (no pipes, simpler source).

I found a variant of flex called reflex which seems to be similarly good so far.
The pair have worked with a Bison example, so they look promising.

I noticed Autoconf uses m4 so it would probably have complications also.

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.

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?

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?

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

_______________________________________________
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

Reply via email to