no you should be fine…
I just posted new ebuilds for gentoo and submitted them to portage maintainers…
(you can find them on a post I just made in this forum… try those and see if the work for ya)
Interrogate is a C++ parser which Panda3D uses to generate python wrappers from C++ code. It works fine as long as the code is in standards compliant C++, but the problem is, system header files are generally not standards compliant. We always have to work around the C++ extensions we find in these system header files. Apparently, your system header files contain something that we haven’t dealt with yet. Could you show the offending line of code in “types.h”?
here is entire types.h since it has just 39 lines
file:
#ifndef _ASM_X86_TYPES_H
#define _ASM_X86_TYPES_H
#ifndef __ASSEMBLY__
typedef unsigned short umode_t;
/*
* __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
* header files exported to user space
*/
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
#ifdef __i386__
# ifdef __GNUC__
__extension__ typedef __signed__ long long __s64;
__extension__ typedef unsigned long long __u64;
# endif
#else
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#endif /* __ASSEMBLY__ */
/*
* These aren't exported outside the kernel to avoid name space clashes
*/
#endif
Line in question would be this
typedef signed char __s8;
#ifndef _I386_TYPES_H
#define _I386_TYPES_H
#ifndef __ASSEMBLY__
typedef unsigned short umode_t;
/*
* __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
* header files exported to user space
*/
typedef __signed__ char __s8;
typedef unsigned char __u8;
typedef __signed__ short __s16;
typedef unsigned short __u16;
typedef __signed__ int __s32;
typedef unsigned int __u32;
#if (defined(__GNUC__) && !defined(__STRICT_ANSI__)) || (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L)
typedef __signed__ long long __s64;
typedef unsigned long long __u64;
#endif
#endif /* __ASSEMBLY__ */
/*
* These aren't exported outside the kernel to avoid name space clashes
*/
#endif
Looks like there are some differences …
Have you been installing any masked packages or are you using a portage overlay such as beryl? (just a shot in the dark here)
types.h belong to linux kernel… running 4 example
equery b /usr/include/asm/types.h
[ Searching for file(s) /usr/include/asm/types.h in *… ]
sys-kernel/linux-headers-2.6.24 (/usr/include/asm/types.h)
And yes I’m using sabayon overlay, since I used their compiled
live distro 4 install. But the linux-headers seems to belong to
master tree of portage.
The strange thing is that it throws error on the line that you also have,
thats really confusing me now.
Btw. Im using Python 2.5.1
I just tried replace the file in question and it gives me the same error …
here is entire log of ebuild.
looked over that log file and all I can say is “WOW”
does anything else have this issue?
like… if you try to emerge gvim or something, does it also spew this many warnings and errors?
On a system like this, I would probably rebuild the kernel, glibc and well… everything… (if other things are running into the same errors)
I have tested this ebuild file on two different gentoo machines now…x86 and x86_64 and both build fine. I would seriously consider moving away from a portage overlay and rebuilding.
The normal way we protect the build from troublesome system header files like this is to add a dummy file into dtool/src/parser-inc to shadow the file. The files in this directory are read by interrogate, but not by the actual compiler.
So, in this case, we just need to create an empty types.h in dtool/src/parser-inc, then add “asm/types.h” to the list in the Sources.pp in that directory, so that the new file will be installed as panda3d/include/parser-inc/asm/types.h. Oh yeah, and modify makepanda to copy the file in place as well.
joeldg: this is testing system and beta distro, so It’s nothing strange
aside this I was able to make everything compile without much hassle
drwr: thnx for suggestion , I will try that tomorrow and post the result here
as far the editing makepanda, I didn’t understand if I need to copy
original types.p to panda includes or what… And anyway I guess
that wouldn’t be necessary for panda to compile.
Unfortunately same error persist
*** Error in /usr/include/asm/types.h near line 13, column 25:
syntax error, unexpected KW_CHAR, expecting '{' or ';' or ':' or '='
Error parsing file: 'asyncTaskManager.h'
joeldg: what version of kernel,gcc python do you have ?
[Edit]
I managed to compile it with dirty hack … mv /include/asm/types.h /include/asm/types.h.orig
touch /include/asm/types.h
compile … move back … compile … again mv and touch and manualy install
now I’m having it in /opt/panda3d and it’s working
but It would be nice to have it within ebuild