I just noticed that with the new implementation of
___arch__swab64 in 2.4.21 (i386), kdemultimedia-3.1.x won't
compile. Basically it tries to include <linux/cdrom.h>, which
in turn tries to include <asm/byteorder.h>, and it tries to
compile it all with g++ -ansi. ___arch__swab64() is partly to
blame.
Now as much as we may call this a KDE bug, the old
___arch__swab64 implementation didn't have this problem. In the
old implementation, both the __u64 type (from <asm/types.h>) and
the ___arch__swab64() macro (which depends on the __u64 type)
didn't get defined in userland for __STRICT_ANSI__ code.
With the new implementation taken from SGI XFS, __u64 still isn't
defined for __STRICT_ANSI__ code, but ___arch__swab64() is
exposed to the world no matter what. Run that through gcc
-ansi, and you get an instant parse error! ;)
That's reason enough to rectify this annoying little
inconsistency. I suggest we either let both code bits stay with
__STRICT_ANSI__ defined, or we leave out at least the
___arch__swab64() macro with __STRICT_ANSI__ defined. I'm
personally in favor of putting the old __STRICT_ANSI__ check
around the new ___arch__swab64().
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"