[Clfs-support] Problem with Linux (2.6.17.13-09092006) header

[Ken Moffat]

On Mon, Nov 19, 2007 at 12:15:21AM -0800, David Whitney wrote:
> Hello,
> 
> I've been trying to track down the URL where I can look for additional
> patches (if any) for the Linux kernel that I used to build CLFS.  I am
> having trouble compiling an application that uses the swab.h header file in
> the /usr/include/linux/byteorder directory.
> 
 Sounds like the wrong fix.  In the early days of the clfs
linux-headers there were occasional problems down the line caused by
missing headers, but in those rare cases the fix is to fix the
headers, not the kernel.
> Here's the error I am getting:
> archiver Makefile - compiling: source/cdrom/ArcCDInterface.cpp
> In file included from
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/little_endian.h:12,
>                  from
> /home/whitney/olymed/olylfs/usr/include/asm/byteorder.h:6,
>                  from
> /home/whitney/olymed/olylfs/usr/include/linux/cdrom.h:14,
>                  from source/cdrom/ArcCDInterface.cpp:25:
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:80:1: error:
> "___constant_swab16" redefined
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:55:1: error:
> this is the location of the previous definition
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:81:1: error:
> "___constant_swab32" redefined
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:59:1: error:
> this is the location of the previous definition
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:82:1: error:
> "___constant_swab64" redefined
> /home/whitney/olymed/olylfs/usr/include/linux/byteorder/swab.h:65:1: error:
> this is the location of the previous definition
> make[1]: *** [release/cdrom/ArcCDInterface.o] Error 1
> 
> 
> Upon examination of swab.h, it is quite apparent what is causing the issue.
> Here's a sample:
> 
>  55 #define ___constant_swab16(x) \
>  56         ((__u16)( \
>  57                 (((__u16)(x) & (__u16)0x00ffU) << 8) | \
>  58                 (((__u16)(x) & (__u16)0xff00U) >> 8) ))
> ...
>  80 #define ___constant_swab16(x) __bswap_constant_16(x)
> 
> Normally the redeclaration of a constant, or in this case a macro, would
> cause a warning to be issued by GCC, however I am compiling with the -Werror
> option.  Either way, it seems odd that a multiple definition of this macro
> exists.  I've noticed in the headers for kernel 2.6.23.1-21 on my Fedora 7
> system the issue no longer exists.  Is there a remedy for this issue (i.e. a
> patch) if I wish to remain using the kernel version 2.6.17.13 as specified
> in the CLFS-1.0 guide?
> 
> Thank you in advance for your suggestions.
> 
 I no longer use the clfs headers, but I suppose you could compare
what is in the current version (for the development book) to see if
it has changed.  That looks as if line 80 might have the arguments
reversed, but I don't have any bswap_constant_16 references in the
headers on this system, so I'm probably wrong.

 You are also making a fundamental mistake: the kernel headers
encapsulate the interfaces to userspace that were around when glibc
was built.  So, you do not reinstall the headers when you upgrade
the kernel (fedora _might_ do things differently, because they will
allow glibc upgrades during the supported life of a distro).  In
fact, unless you have to fix an error in the headers, you don't
alter them until you replace the system.  But, upgrading to a newer
kernel is usually a good idea (upstream bugfixes and security
fixes) - obviously, that won't help with this problem.

 But, why would you *want* to use -Werror ?  If you aren't the
maintainer of the code, it is unlikely to help and very likely to
suddenly prevent compilation when gcc is upgraded.

 You don't specify what the package is, and google didn't find any
matches for the cpp file, so it might well be a problem with the
headers.  But in general, as you stray from the common path (and on
clfs, not many people are here, so the common packages are few) you
increasingly have to apply fixes to packages so that they will
build.  If something is in cblfs, that might already have a fix.  If
not, look at gentoo ebuilds (a sort of shell script, the best are
sufficiently commented, and sometimes they use patches), and failing
that anything in srpm spec files, or patches in srpms, or patches
from other distros, or occasionally from the bug system for the
package (not always nice, e.g. debian put the patches into a script
which makes them hard to extract, mandrake cooker gets a lot of
references on google but very few of them find what was indexed.

 Oh, and if you are messing with your mail headers, please don't -
you nearly got a personal reply with nothing for the list.  On all
{,b,c}lfs lists, it's normal to reply to the lists (so, we have to
make an effort to do off-list replies).  Other lists do things
differently.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce