# Building parse.o

**URL:** <https://www.ruby-forum.com/t/building-parse-o/89144>\
**Category:** Ruby\
**Created:** [January 3, 2006, 11:55pm UTC](https://www.ruby-forum.com/t/building-parse-o/89144 "2006-01-03T23:55:00Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [January 3, 2006, 11:55pm UTC](https://www.ruby-forum.com/t/building-parse-o/89144/1 "2006-01-03T23:55:00Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [January 4, 2006, 2:06am UTC](https://www.ruby-forum.com/t/building-parse-o/89144/2 "2006-01-04T02:06:32Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\
**Post date:** [January 4, 2006, 6:38pm UTC](https://www.ruby-forum.com/t/building-parse-o/89144/3 "2006-01-04T18:38:55Z")

</div>

Quoting Lou V. [removed\_email\_address@domain.invalid](mailto: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