[M3devel] building m3gdb on AMD64_LINUX

[Jay]

See also C:\dev2\cm3.2\caltech-parser\parserlib\klex\src




 


From: jay.krell at cornell.edu
To: rodney.m.bates at cox.net; m3devel at elegosoft.com
Subject: RE: [M3devel] building m3gdb on AMD64_LINUX
Date: Sat, 4 Jul 2009 15:33:48 +0000



It built ok for me a second time.
The second time I removed /usr/local/cm3/bin from $PATH and deleted and re-cvs-uped m3-sys/m3gdb.
 
yacc comes from C:\dev2\cm3.2\caltech-parser\parserlib\kyacc\src.
 
As long as nothing depend on running it by that name, and assuming it isn't a faithful replacement for other Yacc's, probably should rename it m3yacc, or kyacc, whatever that means.
 
You might just try rm -rf m3gdb and cvs -z3 upd -dAP.
Maybe there is/was a timestamp problem.
As Rodney said, it shouldn't need to run yacc, even if your yacc is messed up.
 
  - Jay

 


From: jay.krell at cornell.edu
To: rodney.m.bates at cox.net; m3devel at elegosoft.com
Date: Sat, 4 Jul 2009 15:28:24 +0000
Subject: Re: [M3devel] building m3gdb on AMD64_LINUX



It built ok for me, but there is a suspicous /usr/local/cm3/bin/yacc.
I'm investigating more, but maybe not right now.
 
 - Jay

 
> Date: Fri, 3 Jul 2009 16:53:31 -0500
> From: rodney.m.bates at cox.net
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] building m3gdb on AMD64_LINUX
> 
> On my AMD64_LINUX machine (Ubuntu 8.04.2), on which m3gdb builds, yacc
> is circuitously symlinked to a script that executes /usr/bin/bison -y.
> 
> In any case, usually, there is no need to execute yacc when building 
> (m3)gdb,
> because its output is already present and newer than yacc's input, in 
> this case,
> c-exp.y. I think this is the way it is in the CVS repository. Did some 
> dates
> in your source copy get touched?
> 
> I have no idea where the c-exp.t file it wants is supposed to come from.
> In a brief look, I didn't find any reference to a *.t file at all, 
> either in the script
> m3gdb/gdb/ylwrap, nor in the yacc man page (which actually leads to the
> bison man page on my machine). Maybe original yacc does something 
> with it. 
> I would have thought ylwrap would have been written to work with a number
> of varieties of yacc and equivalents. 
> 
> Do you have a copy of c-exp.y?
> 
> I suspect having a newer c-exp.c than c-exp.y will circumvent this 
> problem, but
> of course we probably want it set up to work when c-exp.c needs to be 
> rebuilt.
> 
> Olaf Wagner wrote:
> > building m3gdb on birch ends with
> >
> > gcc -c -g -I. -I../../gdb/gdb -I../../gdb/gdb/config 
> > -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H 
> > -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../readline/.. 
> > -I../bfd -I../../gdb/gdb/../bfd -I../../gdb/gdb/../include -I../intl 
> > -I../../gdb/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type 
> > -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith 
> > -Wformat-nonliteral -Wunused-label -Wunused-function 
> > ../../gdb/gdb/tui/tui-winsource.c
> > /bin/sh ../../gdb/gdb/../ylwrap ../../gdb/gdb/c-exp.y y.tab.c 
> > c-exp.c.tmp -- yacc
> > Cannot open 
> > "/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb/../../gdb/gdb/c-exp.t" 
> >
> > make[2]: *** [c-exp.c] Error 1
> > make[2]: Leaving directory 
> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/gdb'
> > make[1]: *** [all-gdb] Error 2
> > make[1]: Leaving directory 
> > `/home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX'
> > make: *** [all] Error 2
> > "/home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile", line 121: quake 
> > runtime error: exit 2: make CC="gcc" CFLAGS="-g" MAKEINFO=echo
> >
> > --procedure-- -line- -file---
> > exec -- <builtin>
> > m3gdb_Run 121 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile
> > include_dir 160 /home/wagner/work/cm3/m3-sys/m3gdb/src/m3makefile
> > 4 
> > /home/wagner/work/cm3/m3-sys/m3gdb/AMD64_LINUX/m3make.args
> >
> > Fatal Error: package build failed
> >
> > Any hints? Wrong yacc?
> >
> > Olaf
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090704/f0860c9b/attachment-0002.html>