glibc doesn't build with linux-header-2.6.28 on loongson
Update: It is said that this problem has already been fixed. I will test it later.
Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here.
To make long story short, please take a look at these two files first:
The first file, which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file.
The second file, which will be /usr/include/linux/byteorder.h
Obviously, this test in the second file will fail:
It seems that there is an inconsistency between Linux and glibc on handling __LITTLE_ENDIAN and __BIG_ENDIAN. Linux treats them like a flag, while glibc treats them like a value. glibc uses __BYTE_ORDER to determine the endianness.
This problem must be solved, or any userland program including kernel headers which include {asm,linux}/byteorder.h will fail to build, e.g. glibc.
It seems to me that the most straight forward way, but also very intrusive way is to make the handling of these two marco consistent in the two projects. That'll be a very large changeset. Also it will suddenly change a convention in a project that has already been followed for a long time. So I don't think people will accept this.
How this problem will be solved is still remained to be seen.
EDIT: someone reported that it worked well on ~amd64. So I modified the title and removed the last sentence. I will see if this problem still exists on my x86 notebook.
EDIT 2: I confirm that this problem does not exists on x86. I will find out what exactly is going on loongson, or rather mips. :)
Actually I intended to send this to LKML, but just before I was about to send I found there was already some discussions about this . So instead I decided to just post it here.
To make long story short, please take a look at these two files first:
The first file, which will become part of /usr/include/endian.h. This file defines both __LITTLE_ENDIAN and __BIG_ENDIAN. And this file will be included by the second file.
The second file, which will be /usr/include/linux/byteorder.h
Obviously, this test in the second file will fail:
#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
# error Fix asm/byteorder.h to define one endianness
#endif
This problem must be solved, or any userland program including kernel headers which include {asm,linux}/byteorder.h will fail to build, e.g. glibc.
It seems to me that the most straight forward way, but also very intrusive way is to make the handling of these two marco consistent in the two projects. That'll be a very large changeset. Also it will suddenly change a convention in a project that has already been followed for a long time. So I don't think people will accept this.
How this problem will be solved is still remained to be seen.
EDIT: someone reported that it worked well on ~amd64. So I modified the title and removed the last sentence. I will see if this problem still exists on my x86 notebook.
EDIT 2: I confirm that this problem does not exists on x86. I will find out what exactly is going on loongson, or rather mips. :)
Comments
Duncan
一直不知道哪里可以获得关于gentoo的动态，三天前使用~amd64编译不过，总是提示glibc编译错误（或是glib？），我不大懂编程，这类错误只能白眼，结果系统安不下去，无奈在磁盘上划了一个lv把archlinux装上了。现在问题解决没有？
Plus, you need to be very specific about the name of the package when reporting bugs. "glibc" or "glib" is unacceptable.
As to the problem itself, I have started to look at it yet.
please take a look here