I grabbed Xorg's 7.X beta-1. Got as far as xorg-server when something like the following appeared:

Naturaly, I assumed its a problem with Xorg7, especially being Beta! However, looking at the file that was giving the problem xorg-server-*/hw/xfree86/os-support/linux/lnx_agp.c, where the following was declared:
I could not find anything wrong here, so I looked into the <linux/agpart.h> file. Nothing seemed wrong here. Further searching I found myself inside <linux/types.h> where __u16 and __u32 are declared. And found that I had to go to <stdint.h> to find where u_int16_t and u_int32_t are defined.

I found those simply mean: unsigned short int for 16-bit unsigned integer, and the unsigned int for the 32-bit unsigned integer.

I then changed all occurances of __u16 to unsigned short int and __u32 to unsigned int in /usr/include/linux/agpart.h.

I tried make again under the xorg-server tree, and this time it went through without any errors.

The following Defines seem to be of possible importance:
__int8_t_defined from <stdint.h>
__KERNEL_STRICT_NAMES from <linux/types.h>
__BIT_TYPES_DEFINED__ from <linux/types.h>

I also noticed that __u16 and __u32 are declared twice in this file. Once under the __BIT_TYPES_DEFINED__ and then a second time immediately under the endif of __BIT_TYPES_DEFINED__, and __BIT_TYPES_DEFINED__ has no #else declared.

The __BIT_TYPES_DEFINED__ declares __u16 and __u32 to different typedefs that can be found in <sys/types.h>, which end up being the same structure as those in <stdint.h>

What is going on here?
Does Xorg have to include a certain #define?

Almost forgot, kernel version: 2.6.13.4

- Kevin Day

i would say yes this is an error in kernel headers (Linux-Libc-Headers)
these types of errors don't happen that often but it is a matter of one header being dependant on another
and not getting called in the right order.
Most of the includes use #define constants to fix this type of thing and often with this type of stuff people will just find an easy workaround like you did and move on which i think may actually slow the process of fixing these type of bugs.
since it's not ok to upgrade libc headers you are kind of stuck with them and just working around the problems but most likely this stuff is fixed in the newer versions.

thanks for clearing that up.

This had me wondering for some time now.

edit: That given kernel-headers was version 2.6.12.0.
This makes me worry as it is older than the kernel being used, but no new kernel-headers above this version has been release yet.

it's extreemly important the user space glibc headers (kernel headers in /usr/include) remain the headers used to actually compile glibc. what we do is use the actual headers from the kernel to compile glibc then change the headers to the cleaned up Linux-Libc-Headers of the same version number so internel kernel junk is not exposed. Then when you upgrade the kernel you should leave the userspace headers alone. Suposedly the syscall API will not change so the new kernels will be backward compatable with your glibc.

If you have changed the Linux-Libc-Headers to a version higher than you started out with you should change back.

We used to upgrade the headers along with the kernel years ago and it would lead to degraded performance and stability as new programs were compiled against headers that did not match the userspace symbols in glibc. Linus had to explain at us about that one.

I personally think the headers should to be maintaned by glibc so people stopped thinking of them as kernel headers altogother. they are afterall the headers to glibc and not the kernel.

I am on an LFS or HLFS style system, so I generally unroll the system myself. Putting them into glibc seem to me not such a good idea, as there are numerous other libc's out there (for better or worse..).

Fact is, I am using a uClibc system so I can squeeze the 2-gig glibc system into a 500mb uclibc system, without compression. (and i did)

As a result of using uClibc, I have a lot of wild-cards to worry about when I have problems as it could be uClibc itself, which lead to the question made by this post.

And don't worry, I upgrade my linux-libc-headers only when compiling my system libc.