Bug 478663 - Broken linux/byteorder.h in kernel-headers-2.6.29*
Broken linux/byteorder.h in kernel-headers-2.6.29*
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 469253 478855
  Show dependency treegraph
 
Reported: 2009-01-02 19:48 EST by Jakub Jelinek
Modified: 2009-01-08 17:00 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-08 17:00:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jakub Jelinek 2009-01-02 19:48:23 EST
Description of problem:

With the recent endian changes in kernel headers it is not possible to compile
glibc and I guess plenty of other stuff.  glibc build fails with:
In file included from /usr/include/asm/byteorder.h:63,
                 from /usr/include/linux/atalk.h:4,
                 from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
                 from ../sysdeps/unix/sysv/linux/sa_len.c:22:
/usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness

I guess
#include <endian.h>
#include <asm/byteorder.h>
should be enough to reproduce it.  The problem is that the new kernel headers
now use __BIG_ENDIAN or __LITTLE_ENDIAN macros to determine if target is
big or little endian.  Unfortunately, this clashes with glibc __BIG_ENDIAN
and __LITTLE_ENDIAN macros that are in use for years.  Kernel expects only one
to be defined, while glibc always defines both (well, also __PDP_ENDIAN) and
then defines __BYTE_ORDER to the one that is used for the arch in question.

I'd say the kernel, at least for #ifndef __KERNEL__, should use different macros
than __BIG_ENDIAN and __LITTLE_ENDIAN (add __ at the end or something similar).

Version-Release number of selected component (if applicable):

2.6.29-*

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Gerd Hoffmann 2009-01-05 10:21:51 EST
mock-chroot> cat test.c 
#include <endian.h>
#include <asm/byteorder.h>
mock-chroot> gcc -otest test.c
In file included from /usr/include/asm/byteorder.h:63,
                 from test.c:2:
/usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness
mock-chroot>
Comment 2 Ivana Varekova 2009-01-06 05:03:29 EST
This problem block busybox build too :(:

In file included from /usr/include/asm/byteorder.h:63,
                 from /usr/include/linux/ip.h:20,
                 from /usr/include/linux/if_tunnel.h:5,
                 from networking/libiproute/iptunnel.c:24:
/usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness
Comment 3 Jarod Wilson 2009-01-06 13:07:06 EST
Some upstream discussion on the matter:

http://lkml.org/lkml/2008/12/16/60
Comment 4 Gerd Hoffmann 2009-01-06 18:08:48 EST
Most recent patch set starts here:
http://lkml.org/lkml/2009/1/6/341
Comment 5 Dominik 'Rathann' Mierzejewski 2009-01-06 20:07:38 EST
Bump. I can't build MPlayer because of that.
Comment 6 Dominik 'Rathann' Mierzejewski 2009-01-06 20:09:45 EST
My testcase:

$ cat test.c
#include <sys/types.h> 
#include <linux/cdrom.h>
$ gcc -o test test.c
In file included from /usr/include/asm/byteorder.h:63,
                 from /usr/include/linux/cdrom.h:14,
                 from test.c:2:
/usr/include/linux/byteorder.h:8:3: error: #error Fix asm/byteorder.h to define one endianness
$ rpm -q kernel-headers
kernel-headers-2.6.29-0.12.rc0.git7.fc11.i386
Comment 7 Gerd Hoffmann 2009-01-07 04:44:36 EST
Fixed upstream, patches (comment #4) merged into latest git.
Next kernel update should get us the fix too.
Comment 8 Jarod Wilson 2009-01-07 09:04:28 EST
Should be fixed in kernel-2.6.29-0.15.rc0.git9.fc11 (currently headed to the build system) and later.
Comment 9 Daniel Berrange 2009-01-08 06:10:32 EST
FYI I just did a KVM build, with kernel-headers  2.6.29-0.19.rc0.git9.fc11 in the build root and it now works fine, so looks like this resolved it.
Comment 10 Dominik 'Rathann' Mierzejewski 2009-01-08 16:45:33 EST
It seems to be fixed, thanks.

Note You need to log in before you can comment on or make changes to this bug.