Forum: Ruby building parse.o

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-01-03 23:55
(Received via mailing list)
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
Ce60c4f78a63b0695e4dafc4bd7964f7?d=identicon&s=25 Lou Vanek (Guest)
on 2006-01-04 02:06
(Received via mailing list)
mental@rydia.net 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.
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-01-04 18:38
(Received via mailing list)
Quoting Lou Vanek <vanek@acd.net>:

> 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
This topic is locked and can not be replied to.