Pending package updates, any gotchas?
kelledin+LFS at skarpsey.dyndns.org
Thu Jul 31 22:46:18 PDT 2003
On Wednesday 30 July 2003 10:39 am, Gerard Beekmans wrote:
> On Tue, 2003-07-29 at 18:18, Greg Schafer wrote:
> > The actual kernel is fine. But the kernel headers are a bit
> > broken in that apps that include <linux/cdrom.h> might fail
> > to build. In the case of kdemultimedia, it DOES FAIL to
> > build. See my post about this from a day or 2 ago. But if we
> > used the sanitized headers for /usr/include... <ducks>
> > :-) But I would still update the book with 2.4.21.
Well, here's a kernel patch that corrects the <linux/cdrom.h>
Basically, a new (supposedly faster) implementation of
___arch__swab64 on i386 got taken from the SGI-XFS developers
and merged into 2.4.21. Since ___arch__swab64 relies on the
__u64 type, and the __u64 type isn't defined for gcc -ansi, the
old implementation would not define ___arch__swab64 for gcc
-ansi to avoid parse errors. The new implementation fails to
implement a proper preprocessor check.
The patch puts the preprocessor check back in. I sent it to
lkml; I haven't checked to see if it's merged tho.
kdemultimedia including <linux/cdrom.h> tripped on this, because
<linux/cdrom.h> includes <asm/byteorder.h>, and kde builds with
Oh, BTW, there are other configure checks in KDE that fail loudly
(like raw.h test). I'm not sure how detrimental these are, but
I believe most of these failed tests would pass if KDE packages
didn't try to build with g++ -ansi. Since parts of KDE are
actually kind of platform-specific (like <linux/cdrom.h>), it
seems reasonable to strip out the -ansi option from KDE
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1237 bytes
Desc: not available
More information about the lfs-dev