Building parse.o


#1

Hey, I’ve got this HP-UX 11i box which I’m trying to build Ruby
1.8.4 on. gcc 3.3.2.

Things go well, except it dies on parse.o:

     gcc -g -O2  -DRUBY_EXPORT  -I. -I.  -c parse.c

In file included from parse.y:3338:
keywords:11: error: parse error before ‘{’ token
keywords:45: error: syntax error before ‘{’ token
parse.y: In function `ruby_yylex’:
parse.y:4439: warning: assignment makes pointer from integer
without a cast
*** Error exit code 1

Looking at lex.c:

#line 21 “keywords”
{“for, {kFOR, kFOR}, EXPR_BEG”},
#line 11 “keywords”
{“case, {kCASE, kCASE}, EXPR_BEG”},

That looks valid, and I can’t even find anything which would
correspond to line 45 from keywords. There is, however, this
around line 40ish of lex.c:

unsigned int
{
static unsigned char asso_values[] =
{

That definitely doesn’t look right.

I’ve got gperf 3.0.1. Is this a gperf bug? Has anyone else hit
this before?

-mental


#2

removed_email_address@domain.invalid wrote:

parse.y:4439: warning: assignment makes pointer from integer
without a cast
*** Error exit code 1

Looking at lex.c:

#line 21 “keywords”
{“for, {kFOR, kFOR}, EXPR_BEG”},

this line should read,
{“for”, {kFOR, kFOR}, EXPR_BEG},

#line 11 “keywords”
{“case, {kCASE, kCASE}, EXPR_BEG”},

this line should read,
{“case”, {kCASE, kCASE}, EXPR_BEG},

That looks valid, and I can’t even find anything which would
correspond to line 45 from keywords. There is, however, this
around line 40ish of lex.c:

unsigned int
{
static unsigned char asso_values[] =
{

the ruby source code i downloaded looks like this,

#ifdef GNUC
__inline
#endif
struct kwtable *
rb_reserved_word (str, len)
register const char *str;
register unsigned int len;
{
static struct kwtable wordlist[] =
{
{""}, {""}, {""}, {""}, {""}, {""},
{“end”, {kEND, kEND}, EXPR_END},

That definitely doesn’t look right.

I’ve got gperf 3.0.1. Is this a gperf bug? Has anyone else hit
this before?

-mental

why are you running gperf? lex.c should have come with the rest of the
code already pre-assembled (it did for me).
The entire file, lex.c, is pretty much generic C code. There shouldn’t
be any need to re-generate the file unless you are adding new keywords
into the Ruby language.


#3

Quoting Lou V. removed_email_address@domain.invalid:

why are you running gperf? lex.c should have come with the rest
of the code already pre-assembled (it did for me).

Blame HP-UX’s make.

The entire file, lex.c, is pretty much generic C code. There
shouldn’t be any need to re-generate the file unless you are
adding new keywords into the Ruby language.

It turns out I’ve got two problems:

  1. HP-UX’s make considers a file out-of-date if it is the same
    age as its dependencies – since lex.c is unpacked with the
    same timestamp as keywords, /usr/bin/make decides that it
    needs to be regenerated.

  2. The build of gperf on this box is badly broken

Workaround: touch lex.c before building.

Lesson: Always use gmake.

-mental