Re: [Gems-users] problem compiling ruby part 3

[Dan Gibson <degibson@xxxxxxxx>]

On Sat, Jan 16, 2010 at 2:27 PM, Mladen Nikitovic <mladen@xxxxxx> wrote:

1. Ok, make clean should be fine. I'm using 2.2.19, maybe that's why I could not find any modules.cache anywhere in my directories?

2.2.19 has a modules.cache, too. Its not required, however. I think Simics builds it when it at startup, not at compile-time. When adding new modules, this can confuse things.
 

 

2. I haven't seen this conflict either before. Can you clarify what you mean by "if you get the definitions correct"? Does that mean that I did right in modifying my typedef so that the definition instead comes from /usr/include/stdint.h or should I do it in another way?

I mean that if the sizes and signs are consistent on the typedefs, there shouldn't be any functional problem.
 

 

3. I checked my attrlex.c file and the strangest thing is that it has the same exact piece of code like you have. That is why I get puzzled by all the messages saying that it is not defined. At least one of the definitions should go through depending on whether YY_USE_PROTOS is defined or not.

Well that is very unusual indeed. Try running bison via the command line on attrlex.l and see if there is any unusual output. You will have to grep through Ruby's Makefile to find the exact command. The line you're looking for probably starts with $(LEX) or maybe $(BISON).
 

 

Regards,

Mladen

---

Från: gems-users-bounces@xxxxxxxxxxx [gems-users-bounces@xxxxxxxxxxx] för Dan Gibson [degibson@xxxxxxxx]
Skickat: den 16 januari 2010 20:41
Till: Gems Users
Ämne: Re: [Gems-users] problem compiling ruby part 3

1. 'make clean' should be sufficient to resolve most compile-time transients. There IS benefit to removing Simics's module cache (a file called modules.cache), though I don't know where that file lives in Simics 3.x

2. I haven't seen the conflicts with stdint.h and unistd.h before. It might be redhat-specific... anyway, if you get the definitions correct (e.g., uint64 is a uint64, etc.) it should be OK.

3. I had a look at my own attrlex.c: yy_fatal_error is defined at the bottom of the file. Unfortunately, I have no idea why it does not appear in YOUR attrlex.c. Again, I suspect its absence is somehow specific to your host configuration. At any rate, there are a couple of work-arounds that are possible. I think the easiest would be for you to just manually add a definition for yy_fatal_error. Bear in mind that if you make clean, attrlex.c will go away, so keep a safe copy of your modified attrlex.c.

Here's my definition of attrlex's yy_fatal_error -- hopefully it works for you, too.
1659 #ifdef YY_USE_PROTOS
1660 static void yy_fatal_error( yyconst char msg[] )
1661 #else
1662 static void yy_fatal_error( msg )
1663 char msg[];
1664 #endif
1665   {
1666   (void) fprintf( stderr, "%s\n", msg );
1667   exit( YY_EXIT_FAILURE );
1668   }

Good luck.

Regards,
Dan

On Sat, Jan 16, 2010 at 12:05 PM, Mladen Nikitovic <mladen@xxxxxx> wrote:

Just some additional info, this error is something I get before the yy_fatal_error issue. I'm trying to compile ruby using release1.2 together with simics 2.2.19 on a machine x86 machine running redhat (64-bit). I used the simcs configure script so that gcc/g++ 3.4.6 is used. Issuing make with PROTOCOL/DESTINATION=MSI_MOSI_CMP_directory gives me this:

 

../simics/x86-linux/obj/include/simics/types_api.h:203: error: conflicting declaration 'typedef int64 intptr_t'
/usr/include/unistd.h:238: error: 'intptr_t' has a previous declaration as 'typedef __intptr_t intptr_t'
../simics/x86-linux/obj/include/simics/types_api.h:211: error: conflicting declaration 'typedef uint64 uintptr_t'
/usr/include/stdint.h:123: error: 'uintptr_t' has a previous declaration as 'typedef long unsigned int uintptr_t'
make[1]: *** [x86-linux/generated/MSI_MOSI_CMP_directory/obj/attrparse.o] Error 1
make[1]: Leaving directory `/mnt/olddisk/localdisk/mladen/amc/gems-release1.2/ruby'

If I change the correspoding typedef to typedef "int64 intptr_t_mladen;" and "typedef uint64 uintptr_t_mladen;" then I can get further but eventually I get:

 

generated/MSI_MOSI_CMP_directory/attrlex.c:303: error: 'void yy_fatal_error(const char*)' used but never defined

I'm using make clean between the tries, so the files should be clean right? If no I would appreciate if someone could show how to "clean" the files properly.

 

Also, I've checked my bison version and it seems to be 2.3. 

 

I've searched the entire GEMS archive and only found one person with the same problems, but no suggested solution.

 

Regards,

Mladen 

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

--
http://www.cs.wisc.edu/~gibson [esc]:wq!

_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/" to your search.

-- 
http://www.cs.wisc.edu/~gibson [esc]:wq!