Pending package updates, any gotchas?

Kelledin 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> 
issue.

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 
g++ -ansi.

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 
makefiles.

-- 
Kelledin
"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...
Name: linux-2.4.21-swab64.patch
Type: text/x-diff
Size: 1237 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20030801/458fd741/attachment.patch>


More information about the lfs-dev mailing list