Bug 478663

Summary: Broken linux/byteorder.h in kernel-headers-2.6.29*
Product: [Fedora] Fedora Reporter: Jakub Jelinek <jakub>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: urgent    
Version: rawhideCC: berrange, dominik, jarod, kernel-maint, kraxel, quintela, rpm, varekova
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-08 22:00:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 469253, 478855    

Description Jakub Jelinek 2009-01-03 00:48:23 UTC
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 15:21:51 UTC
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 10:03:29 UTC
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 18:07:06 UTC
Some upstream discussion on the matter:

http://lkml.org/lkml/2008/12/16/60

Comment 4 Gerd Hoffmann 2009-01-06 23:08:48 UTC
Most recent patch set starts here:
http://lkml.org/lkml/2009/1/6/341

Comment 5 Dominik 'Rathann' Mierzejewski 2009-01-07 01:07:38 UTC
Bump. I can't build MPlayer because of that.

Comment 6 Dominik 'Rathann' Mierzejewski 2009-01-07 01:09:45 UTC
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 09:44:36 UTC
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 14:04:28 UTC
Should be fixed in kernel-2.6.29-0.15.rc0.git9.fc11 (currently headed to the build system) and later.

Comment 9 Daniel Berrangé 2009-01-08 11:10:32 UTC
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 21:45:33 UTC
It seems to be fixed, thanks.