On Mon, Mar 03, 2008 at 11:17:47AM -0500, Russ Cox wrote:
> > I am trying to install plan9port on a Linux system (Debian),
> > and am getting the following error:
> >
> > 9 yacc -d -s bc bc.y
> >
> > fatal error:can't create , <nil>:1
> > mk: 9 yacc -d ... : exit status=exit(1)
> > mk: for i in ... : exit status=exit(1)
>
> The <nil> is just because the error has happened
> very early and yacc hasn't opened the input file yet.
> If you poke around in the code you'll find that
> it was trying to create bc.tab.h (or should have been)
> but somehow this code (stem="bc", FILED = "tab.h"):
>
> sprint(buf, "%s.%s", stem, FILED);
> fdefine = Bopen(buf, OWRITE);
> if(fdefine == 0)
> error("can't create %s", buf);
>
> ended up with an empty string in buf instead of bc.tab.h.
At that point in the code, stem is set to "bc" as expected.
> > So, any ideas on how to fix the build process? The problem
> > stems from yacc.c at line #2173 in the sprint() function.
> > Could I replace that with the standard library sprintf()
> > function as a stop-gap measure?
>
> It would be interesting to know if that makes it work,
> but more interesting would be why the Plan 9 sprint
> is broken. This is a pretty simple sprint call and should work.
For what its worth, I just added the following lines to
yacc.c at the top of the file:
#include <stdio.h>
#define sprint sprintf
The build of plan9port just completed with no errors, the
problem is somewhere in sprint().
I'll try and find time tonight to test out the plan9port
build to verify it works. Let me know if I can provide any
other useful information. I might try tracking down the bug
later this week, but not certain I'll have much time to do
so.
> Can you reproduce the prolem if you just run:
>
> cd /usr/local/plan9/src/cmd
> 9 yacc -s bc bc.y
>
> ?
Yes, I get the exact same output.
> I'm also interested to see the output of:
>
> nm /usr/local/plan9/bin/yacc | grep sprint
Here is the result:
0804fbe0 T sprint
> @erik:
> > once that is fixed, it would be interesting to see if yacc
> > prints a usage statement instead of printing the garbage.
>
> The command line passed in the mkfile has worked in
> thousands of other builds. Even if stem was nil, buf
> should at least end up being "<nil>.tab.h" or ".tab.h"
> or at the very worst, if %s was broken, ".".
Makes sense.
> I doubt the command line is being misparsed, but
> I don't have any justifiable alternate theories.
My first thought was also the command-line was not being
parsed, but gdb shows stem is set to "bc" as expected. Its
why I suspect the problem somewhere under sprint().
--David
