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?"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 30 2003 - 22:00:33 EST