LinuxSir.cn,穿越时空的Linuxsir!

 找回密码
 注册
搜索
热搜: shell linux mysql
查看: 819|回复: 0

glibc doesn't build with linux-header-2.6.28 on loongson

[复制链接]
发表于 2009-2-15 22:06:37 | 显示全部楼层 |阅读模式
小弟最近在根据最新的手册为龙芯2F做clfs,遇到了这个问题,不知道这个问题怎么解决,下面是引用的别人对这个问题的描述:
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
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.
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部 返回列表