Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: > Yeah, this is a VirtualBox problem. > > At this point, this is clearly a matter for innotek, not for the > mainstream kernel development community. Ok I will report that to Innotek , thanks for all the help and sorry for the noise. > > -hpa > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Add a #include to the-linux-kernel.h and let us know if it helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) && __GNUC__ < 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) && defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; <- line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include . Yeah, this is a VirtualBox problem. At this point, this is clearly a matter for innotek, not for the mainstream kernel development community. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Sam Ravnborg wrote: > On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: >> Gabriel C wrote: > BITS_PER_LONG was originally set in : > > 39 #ifdef CONFIG_X86_32 > 40 # define BITS_PER_LONG 32 > 41 #else > 42 # define BITS_PER_LONG 64 > 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? >> Wait... this is *user mode* code at this point? > No - it is a kernel module. > But what a messy codebase to look at... > >> Linux kernel headers aren't includable from user space without >> processing them through "make headers_install". >> >> However, from looking at the filenames in your list, it doesn't look >> like userspace code at all (although they're wrappered to the degree >> that it's somewhat hard to tell.) Thus, you're building a kernel >> module, not userland. >> >>> That is the problem. I've changed the headers virtualbox need from >>> >>> #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. >>> >>> ( subarch headers includes are changed manually still but I think it is >>> the same problem ) >>> >>> Also all the headers got these defines with CONFIG_X86_32 does not work. >>> >>> ... >>> >>> #ifdef CONFIG_X86_32 >>> # include "foo_32.h" >>> #else >>> # include "foo_64.h" >>> #endif >>> >>> ... >>> >>> results in including both header files on my i686 box. >>> >>> I don't know what the right way is to fix that , define some who >>> CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? >> It sounds like something is seriously broken in your setup, or in the >> VirtualBox makefiles. From the looks of it, I would say the latter. > >>From the file "the-linux-kernel.h": > /* > * Include iprt/types.h to install the bool wrappers. > * Then use the linux bool type for all the stuff include here. > */ > #include > #define bool linux_bool > > And that file named "types.h" is not a kernel types.h - so we miss that > file. I guess it was pulled in by some other headerfile in the past. > > But I also notice that it latest source from VirtualBox the > line number for include of spinlock-h does not match. > > > This is most likely a combination of VirtualBox doing strange strange things > and some deep dependency missing in one of the headerfiles. > > Add a #include to the-linux-kernel.h and let us know if it > helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) && __GNUC__ < 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) && defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; <- line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include . > > Sam > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: > Gabriel C wrote: BITS_PER_LONG was originally set in : 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif >>> User land does not know anything about 'CONFIG_X86_32' right ? > > Wait... this is *user mode* code at this point? > > Linux kernel headers aren't includable from user space without > processing them through "make headers_install". > > However, from looking at the filenames in your list, it doesn't look > like userspace code at all (although they're wrappered to the degree > that it's somewhat hard to tell.) Thus, you're building a kernel > module, not userland. Hmm right is building an kernel modules. > >> That is the problem. I've changed the headers virtualbox need from >> >> #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. >> >> ( subarch headers includes are changed manually still but I think it is the >> same problem ) >> >> Also all the headers got these defines with CONFIG_X86_32 does not work. >> >> ... >> >> #ifdef CONFIG_X86_32 >> # include "foo_32.h" >> #else >> # include "foo_64.h" >> #endif >> >> ... >> >> results in including both header files on my i686 box. >> >> I don't know what the right way is to fix that , define some who >> CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? > > It sounds like something is seriously broken in your setup, or in the > VirtualBox makefiles. From the looks of it, I would say the latter. > > It would help to see how gcc is invoked, but your email message doesn't > include any gcc invocations, and your "full error log" weblink is > broken, so it's hard to say. Sorry that box was down some hours I've tested some hardware. Here is a full build log , virtualbox build against cfa76f024f7c9e65169425804e5b32e71f66d0ee : http://194.231.229.228/virtualbox-build.log.tar.bz2 Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: > Gabriel C wrote: > >>>BITS_PER_LONG was originally set in : > >>> > >>> 39 #ifdef CONFIG_X86_32 > >>> 40 # define BITS_PER_LONG 32 > >>> 41 #else > >>> 42 # define BITS_PER_LONG 64 > >>> 43 #endif > >>User land does not know anything about 'CONFIG_X86_32' right ? > > Wait... this is *user mode* code at this point? No - it is a kernel module. But what a messy codebase to look at... > > Linux kernel headers aren't includable from user space without > processing them through "make headers_install". > > However, from looking at the filenames in your list, it doesn't look > like userspace code at all (although they're wrappered to the degree > that it's somewhat hard to tell.) Thus, you're building a kernel > module, not userland. > > >That is the problem. I've changed the headers virtualbox need from > > > >#ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. > > > >( subarch headers includes are changed manually still but I think it is > >the same problem ) > > > >Also all the headers got these defines with CONFIG_X86_32 does not work. > > > >... > > > >#ifdef CONFIG_X86_32 > ># include "foo_32.h" > >#else > ># include "foo_64.h" > >#endif > > > >... > > > >results in including both header files on my i686 box. > > > >I don't know what the right way is to fix that , define some who > >CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? > > It sounds like something is seriously broken in your setup, or in the > VirtualBox makefiles. From the looks of it, I would say the latter. >From the file "the-linux-kernel.h": /* * Include iprt/types.h to install the bool wrappers. * Then use the linux bool type for all the stuff include here. */ #include #define bool linux_bool And that file named "types.h" is not a kernel types.h - so we miss that file. I guess it was pulled in by some other headerfile in the past. But I also notice that it latest source from VirtualBox the line number for include of spinlock-h does not match. This is most likely a combination of VirtualBox doing strange strange things and some deep dependency missing in one of the headerfiles. Add a #include to the-linux-kernel.h and let us know if it helps. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: BITS_PER_LONG was originally set in : 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? Wait... this is *user mode* code at this point? Linux kernel headers aren't includable from user space without processing them through "make headers_install". However, from looking at the filenames in your list, it doesn't look like userspace code at all (although they're wrappered to the degree that it's somewhat hard to tell.) Thus, you're building a kernel module, not userland. That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include "foo_32.h" #else # include "foo_64.h" #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? It sounds like something is seriously broken in your setup, or in the VirtualBox makefiles. From the looks of it, I would say the latter. It would help to see how gcc is invoked, but your email message doesn't include any gcc invocations, and your "full error log" weblink is broken, so it's hard to say. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
>> BITS_PER_LONG was originally set in : >> >> 39 #ifdef CONFIG_X86_32 >> 40 # define BITS_PER_LONG 32 >> 41 #else >> 42 # define BITS_PER_LONG 64 >> 43 #endif > > User land does not know anything about 'CONFIG_X86_32' right ? That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include "foo_32.h" #else # include "foo_64.h" #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: > Gabriel C wrote: >> Hi, >> >> usually I'll wait for rc1 and test compile external module to see which are >> broken and what need fixing >> but while I need virtualbox for some tests I test compile it on current git >> and it failed badly. >> >> Maybe something is missing from x86 merge ? >> >> Here is what I get : >> >> ... >> >> /linux/memobj-r0drv-linux.c >> In file included from >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265, >> from >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2, >> from >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock_32.h:4, >> from >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock.h:2, >> from >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/linux/spinlock.h:87, >> from >> /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h:53, >> from >> /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c:22: >> /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm-generic/atomic.h:23: >> error: expected '=', ',', ';', 'asm' or '__attribute__' before >> 'atomic_long_t' > > I have been unable to make heads or tails of the maze of twisty > dependencies that VirtualBox wants, but the fact that it gets to line 23 > of means it has gotten past: > > 21 #if BITS_PER_LONG == 64 > 22 > 23 typedef atomic64_t atomic_long_t; > > BITS_PER_LONG was originally set in : > > 39 #ifdef CONFIG_X86_32 > 40 # define BITS_PER_LONG 32 > 41 #else > 42 # define BITS_PER_LONG 64 > 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? I just changed some things manually to test , s/CONFIG_X86_32/__i386__/ in asm/types.h and worked fine but subarch headers are still not included probably for the same reason. ( manually changed to test as well ) After doing so , the part filed compiled. but next error a bit later : .. In file included from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/string.h:25, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/assert.cpp:24: /lib/modules/2.6.23-rc0/build/include/linux/string.h:70: error: declaration of C function '__kernel_size_t strlen(const char*)' conflicts with /lib/modules/2.6.23-rc0/build/include/asm/string_64.h:53: error: previous declaration 'size_t strlen(const char*)' here /lib/modules/2.6.23-rc0/build/include/linux/string.h:101: error: declaration of C function 'int memcmp(const void*, const void*, __kernel_size_t)' conflicts with /lib/modules/2.6.23-rc0/build/include/asm/string_64.h:52: error: previous declaration 'int memcmp(const void*, const void*, size_t)' here .. And again both 32/64 things are defined at the same time. > > The most obvious reason for failure is that the symbol CONFIG_X86_32 > isn't being defined where expected. From that point on everything goes > to hell. Yes you are right but as I said above I don't think user land understands CONFIG_X86_32. > > Have you done "make oldconfig && make prepare" in your kernel tree since > you last updated it? Yes I always do that. > > -hpa > > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: Gabriel C wrote: Hi, usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing but while I need virtualbox for some tests I test compile it on current git and it failed badly. Maybe something is missing from x86 merge ? Here is what I get : ... /linux/memobj-r0drv-linux.c In file included from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock_32.h:4, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/linux/spinlock.h:87, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h:53, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c:22: /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm-generic/atomic.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atomic_long_t' I have been unable to make heads or tails of the maze of twisty dependencies that VirtualBox wants, but the fact that it gets to line 23 of asm-generic/atomic.h means it has gotten past: 21 #if BITS_PER_LONG == 64 22 23 typedef atomic64_t atomic_long_t; BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? I just changed some things manually to test , s/CONFIG_X86_32/__i386__/ in asm/types.h and worked fine but subarch headers are still not included probably for the same reason. ( manually changed to test as well ) After doing so , the part filed compiled. but next error a bit later : .. In file included from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/string.h:25, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/assert.cpp:24: /lib/modules/2.6.23-rc0/build/include/linux/string.h:70: error: declaration of C function '__kernel_size_t strlen(const char*)' conflicts with /lib/modules/2.6.23-rc0/build/include/asm/string_64.h:53: error: previous declaration 'size_t strlen(const char*)' here /lib/modules/2.6.23-rc0/build/include/linux/string.h:101: error: declaration of C function 'int memcmp(const void*, const void*, __kernel_size_t)' conflicts with /lib/modules/2.6.23-rc0/build/include/asm/string_64.h:52: error: previous declaration 'int memcmp(const void*, const void*, size_t)' here .. And again both 32/64 things are defined at the same time. The most obvious reason for failure is that the symbol CONFIG_X86_32 isn't being defined where expected. From that point on everything goes to hell. Yes you are right but as I said above I don't think user land understands CONFIG_X86_32. Have you done make oldconfig make prepare in your kernel tree since you last updated it? Yes I always do that. -hpa Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include foo_32.h #else # include foo_64.h #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? Wait... this is *user mode* code at this point? Linux kernel headers aren't includable from user space without processing them through make headers_install. However, from looking at the filenames in your list, it doesn't look like userspace code at all (although they're wrappered to the degree that it's somewhat hard to tell.) Thus, you're building a kernel module, not userland. That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include foo_32.h #else # include foo_64.h #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? It sounds like something is seriously broken in your setup, or in the VirtualBox makefiles. From the looks of it, I would say the latter. It would help to see how gcc is invoked, but your email message doesn't include any gcc invocations, and your full error log weblink is broken, so it's hard to say. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: Gabriel C wrote: BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? Wait... this is *user mode* code at this point? No - it is a kernel module. But what a messy codebase to look at... Linux kernel headers aren't includable from user space without processing them through make headers_install. However, from looking at the filenames in your list, it doesn't look like userspace code at all (although they're wrappered to the degree that it's somewhat hard to tell.) Thus, you're building a kernel module, not userland. That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include foo_32.h #else # include foo_64.h #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? It sounds like something is seriously broken in your setup, or in the VirtualBox makefiles. From the looks of it, I would say the latter. From the file the-linux-kernel.h: /* * Include iprt/types.h to install the bool wrappers. * Then use the linux bool type for all the stuff include here. */ #include iprt/types.h #define bool linux_bool And that file named types.h is not a kernel types.h - so we miss that file. I guess it was pulled in by some other headerfile in the past. But I also notice that it latest source from VirtualBox the line number for include of spinlock-h does not match. This is most likely a combination of VirtualBox doing strange strange things and some deep dependency missing in one of the headerfiles. Add a #include linux/types.h to the-linux-kernel.h and let us know if it helps. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: Gabriel C wrote: BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? Wait... this is *user mode* code at this point? Linux kernel headers aren't includable from user space without processing them through make headers_install. However, from looking at the filenames in your list, it doesn't look like userspace code at all (although they're wrappered to the degree that it's somewhat hard to tell.) Thus, you're building a kernel module, not userland. Hmm right is building an kernel modules. That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include foo_32.h #else # include foo_64.h #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? It sounds like something is seriously broken in your setup, or in the VirtualBox makefiles. From the looks of it, I would say the latter. It would help to see how gcc is invoked, but your email message doesn't include any gcc invocations, and your full error log weblink is broken, so it's hard to say. Sorry that box was down some hours I've tested some hardware. Here is a full build log , virtualbox build against cfa76f024f7c9e65169425804e5b32e71f66d0ee : http://194.231.229.228/virtualbox-build.log.tar.bz2 Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Sam Ravnborg wrote: On Sun, Oct 21, 2007 at 12:15:48PM -0700, H. Peter Anvin wrote: Gabriel C wrote: BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif User land does not know anything about 'CONFIG_X86_32' right ? Wait... this is *user mode* code at this point? No - it is a kernel module. But what a messy codebase to look at... Linux kernel headers aren't includable from user space without processing them through make headers_install. However, from looking at the filenames in your list, it doesn't look like userspace code at all (although they're wrappered to the degree that it's somewhat hard to tell.) Thus, you're building a kernel module, not userland. That is the problem. I've changed the headers virtualbox need from #ifdef CONFIG_X86_32 to #ifdef __i386__ and all compiled fine. ( subarch headers includes are changed manually still but I think it is the same problem ) Also all the headers got these defines with CONFIG_X86_32 does not work. ... #ifdef CONFIG_X86_32 # include foo_32.h #else # include foo_64.h #endif ... results in including both header files on my i686 box. I don't know what the right way is to fix that , define some who CONFIG_X86_32 to __i386__ ? or just s/CONFIG_X86_32/__i386__/ ? It sounds like something is seriously broken in your setup, or in the VirtualBox makefiles. From the looks of it, I would say the latter. From the file the-linux-kernel.h: /* * Include iprt/types.h to install the bool wrappers. * Then use the linux bool type for all the stuff include here. */ #include iprt/types.h #define bool linux_bool And that file named types.h is not a kernel types.h - so we miss that file. I guess it was pulled in by some other headerfile in the past. But I also notice that it latest source from VirtualBox the line number for include of spinlock-h does not match. This is most likely a combination of VirtualBox doing strange strange things and some deep dependency missing in one of the headerfiles. Add a #include linux/types.h to the-linux-kernel.h and let us know if it helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) __GNUC__ 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; - line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include linux/types.h. Sam Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Add a #include linux/types.h to the-linux-kernel.h and let us know if it helps. Does not help , now I get on top the other errors : /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/include/iprt/types.h:121: error: redefinition of typedef 'bool' /lib/modules/2.6.23-gcfa76f02/build/include/linux/types.h:33: error: previous declaration of 'bool' was here ... /* * C doesn't have bool. */ #ifndef __cplusplus # if defined(__GNUC__) # if defined(RT_OS_LINUX) __GNUC__ 3 typedef uint8_t bool; # else # if defined(RT_OS_DARWIN) defined(_STDBOOL_H) #undef bool # endif typedef _Bool bool; - line 121 # endif # else typedef unsigned char bool; # endif # ifndef true # define true (1) # endif # ifndef false # define false (0) # endif #endif Looking at include/iprt/types.h that has already #include linux/types.h. Yeah, this is a VirtualBox problem. At this point, this is clearly a matter for innotek, not for the mainstream kernel development community. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
H. Peter Anvin wrote: Yeah, this is a VirtualBox problem. At this point, this is clearly a matter for innotek, not for the mainstream kernel development community. Ok I will report that to Innotek , thanks for all the help and sorry for the noise. -hpa Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Hi, usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing but while I need virtualbox for some tests I test compile it on current git and it failed badly. Maybe something is missing from x86 merge ? Here is what I get : ... /linux/memobj-r0drv-linux.c In file included from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock_32.h:4, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/linux/spinlock.h:87, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h:53, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c:22: /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm-generic/atomic.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atomic_long_t' I have been unable to make heads or tails of the maze of twisty dependencies that VirtualBox wants, but the fact that it gets to line 23 of means it has gotten past: 21 #if BITS_PER_LONG == 64 22 23 typedef atomic64_t atomic_long_t; BITS_PER_LONG was originally set in : 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif The most obvious reason for failure is that the symbol CONFIG_X86_32 isn't being defined where expected. From that point on everything goes to hell. Have you done "make oldconfig && make prepare" in your kernel tree since you last updated it? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Hi, usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing but while I need virtualbox for some tests I test compile it on current git and it failed badly. Maybe something is missing from x86 merge ? Here is what I get : ... /linux/memobj-r0drv-linux.c In file included from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic_32.h:265, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/atomic.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock_32.h:4, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm/spinlock.h:2, from /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/linux/spinlock.h:87, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/the-linux-kernel.h:53, from /work/crazy/VBox/stable/virtualbox/src/VirtualBox-1.5.2_OSE/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c:22: /lib/modules/2.6.23-g4fa4d23f-dirty/build/include/asm-generic/atomic.h:23: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'atomic_long_t' I have been unable to make heads or tails of the maze of twisty dependencies that VirtualBox wants, but the fact that it gets to line 23 of asm-generic/atomic.h means it has gotten past: 21 #if BITS_PER_LONG == 64 22 23 typedef atomic64_t atomic_long_t; BITS_PER_LONG was originally set in asm/types.h: 39 #ifdef CONFIG_X86_32 40 # define BITS_PER_LONG 32 41 #else 42 # define BITS_PER_LONG 64 43 #endif The most obvious reason for failure is that the symbol CONFIG_X86_32 isn't being defined where expected. From that point on everything goes to hell. Have you done make oldconfig make prepare in your kernel tree since you last updated it? -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Actually I try to get VirtualBox-1.5.2_OSE to compile but I get a lot errors from include/asm-generic/atomic.h and other headers. and looks like some are missing ? /lib/modules/2.6.23-rc0/build/include/asm/irq_32.h:15:25: error: irq_vectors.h: No such file or directory /lib/modules/2.6.23-rc0/build/include/asm/smp_32.h:154:26: error: mach_apicdef.h: No such file or directory Those files are part of the machine subdirectories. I will look at this tomorrow and try to figure out what doesn't get picked up. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Thomas Gleixner wrote: > On Sat, 20 Oct 2007, Gabriel C wrote: >> Gabriel C wrote: >>> Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. >>> Is what I did before latest pull. >>> >>> Maybe this whole tree got broken. I'll try a fresh one and report back. >>> >> >> I get the same on fresh cloned git tree >> >> #-- git rev-parse --verify HEAD >> c4ec20717313daafba59225f812db89595952b83 > > Hmm. The kernel itself compiles fine ? Yes kernel is fine. > > What external thing breaks ? Actually I try to get VirtualBox-1.5.2_OSE to compile but I get a lot errors from include/asm-generic/atomic.h and other headers. and looks like some are missing ? ... /lib/modules/2.6.23-rc0/build/include/asm/irq_32.h:15:25: error: irq_vectors.h: No such file or directory /lib/modules/2.6.23-rc0/build/include/asm/smp_32.h:154:26: error: mach_apicdef.h: No such file or directory ... this is fresh cloned tree and pulled once to get your x86 updates: #-- git rev-parse --verify HEAD 60812a4a99b796d894d2522dc63cb0fafc3be25e Full error log can found there : -> http://194.231.229.228/current-git/errors.txt > > tglx > Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Sat, 20 Oct 2007, Gabriel C wrote: > Gabriel C wrote: > > Jiri Kosina wrote: > >> Trying 'make mrproper' first has high chances of fixing this I'd guess. > > > > Is what I did before latest pull. > > > > Maybe this whole tree got broken. I'll try a fresh one and report back. > > > > > I get the same on fresh cloned git tree > > #-- git rev-parse --verify HEAD > c4ec20717313daafba59225f812db89595952b83 Hmm. The kernel itself compiles fine ? What external thing breaks ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: > Jiri Kosina wrote: >> Trying 'make mrproper' first has high chances of fixing this I'd guess. > > Is what I did before latest pull. > > Maybe this whole tree got broken. I'll try a fresh one and report back. > I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Regards, Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Jiri Kosina wrote: > Trying 'make mrproper' first has high chances of fixing this I'd guess. Is what I did before latest pull. Maybe this whole tree got broken. I'll try a fresh one and report back. Regards , Gabriel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Fri, 19 Oct 2007, Gabriel C wrote: > usually I'll wait for rc1 and test compile external module to see which > are broken and what need fixing but while I need virtualbox for some > tests I test compile it on current git and it failed badly. Maybe > something is missing from x86 merge ? Trying 'make mrproper' first has high chances of fixing this I'd guess. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Thomas Gleixner wrote: On Sat, 20 Oct 2007, Gabriel C wrote: Gabriel C wrote: Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. Is what I did before latest pull. Maybe this whole tree got broken. I'll try a fresh one and report back. I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Hmm. The kernel itself compiles fine ? Yes kernel is fine. What external thing breaks ? Actually I try to get VirtualBox-1.5.2_OSE to compile but I get a lot errors from include/asm-generic/atomic.h and other headers. and looks like some are missing ? ... /lib/modules/2.6.23-rc0/build/include/asm/irq_32.h:15:25: error: irq_vectors.h: No such file or directory /lib/modules/2.6.23-rc0/build/include/asm/smp_32.h:154:26: error: mach_apicdef.h: No such file or directory ... this is fresh cloned tree and pulled once to get your x86 updates: #-- git rev-parse --verify HEAD 60812a4a99b796d894d2522dc63cb0fafc3be25e Full error log can found there : - http://194.231.229.228/current-git/errors.txt tglx Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Actually I try to get VirtualBox-1.5.2_OSE to compile but I get a lot errors from include/asm-generic/atomic.h and other headers. and looks like some are missing ? /lib/modules/2.6.23-rc0/build/include/asm/irq_32.h:15:25: error: irq_vectors.h: No such file or directory /lib/modules/2.6.23-rc0/build/include/asm/smp_32.h:154:26: error: mach_apicdef.h: No such file or directory Those files are part of the machine subdirectories. I will look at this tomorrow and try to figure out what doesn't get picked up. -hpa - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. Is what I did before latest pull. Maybe this whole tree got broken. I'll try a fresh one and report back. Regards , Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Fri, 19 Oct 2007, Gabriel C wrote: usually I'll wait for rc1 and test compile external module to see which are broken and what need fixing but while I need virtualbox for some tests I test compile it on current git and it failed badly. Maybe something is missing from x86 merge ? Trying 'make mrproper' first has high chances of fixing this I'd guess. -- Jiri Kosina - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
On Sat, 20 Oct 2007, Gabriel C wrote: Gabriel C wrote: Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. Is what I did before latest pull. Maybe this whole tree got broken. I'll try a fresh one and report back. I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Hmm. The kernel itself compiles fine ? What external thing breaks ? tglx - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: some kernel headers broken in current git ?
Gabriel C wrote: Jiri Kosina wrote: Trying 'make mrproper' first has high chances of fixing this I'd guess. Is what I did before latest pull. Maybe this whole tree got broken. I'll try a fresh one and report back. I get the same on fresh cloned git tree #-- git rev-parse --verify HEAD c4ec20717313daafba59225f812db89595952b83 Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
