Hi Helge, On Sat, Aug 11, 2007 at 05:56:45PM +0200, Helge Kreutzmann wrote:
> Since I (finally) got a remote shell account on an alpha again I > wanted to do some maintenance on aboot (which has seen no changes > since at least Sarge). However, aboot now ftbfs in Sid. The relevant > lines are: > gcc -g -O2 -Wall -I. -I../include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > "-g" -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 "-g" -c -o ../lib/isolib.o > ../lib/isolib.c > ../lib/isolib.c:10:28: error: linux/string.h: No such file or directory > ../lib/isolib.c:13:26: error: linux/config.h: No such file or directory > In file included from ../lib/isolib.c:21: > ../include/utils.h:5:23: error: asm/hwrpb.h: No such file or directory > These used to be in the kernel headers. They are not contained in > linux-libc-dev (as shipped in sid) and I would rather not include > specific kernel version with specific include paths. > linux/string.h: Still present in current kernels. > linux/config.h: Gone 2.6.22, in 2.6.17 marked as deprecated > asm/hwrpb.h: Still present in (current) kernels > And I'm afraid, the build will fail further down as well (haven't > tested yet). > I tagged this bug "help" because before fiddeling around[1] I thought > I checked what the appropriate way to deal with these missing headers > is. Should I include a copy inside aboot? Should I request them to be > included in linux-libc-dev? Should I (shudder) rely on a specific > kernel version for inclusion? .... - Maybe there is some > documentation/Wiki which explains all these? > Please keep this bug in the loop on replies. Thanks. I took a peek upstream and found that at least part of this was addressed already back in 2003 in the sf cvs tree, so I've gone ahead and merged across from there to the alioth cvs tree as a new vendor import; this addresses linux/string.h, because upstream already has a local copy of this header and the code just needed to be switched to use it. The linux/config.h is apparently a no-op, so I've dropped this reference. And asm/hwrpb.h is solved because the Debian package already has a local copy of this header under include/, for purposes of cross-building. So after these changes and a few more, the package builds again with no need for changes to linux-libc-dev. You can ask for asm/hwrpb.h to be included in l-l-d if you think that's correct, but it looks to me like a case of a header that it's not the kernel's responsibility to provide (because these are firmware interfaces, not kernel interfaces), so I haven't bothered. Two other header fix-ups I've made here are ones I'm almost positive would not be accepted into linux-libc-dev: asm/system.h and asm/pal.h are very much not structured for userspace use, so I've added local copies of these to the Debian CVS. Again, asm/pal.h isn't a kernel interface, and asm/system.h is 90% stuff that's not supposed to be depended on by userspace -- the only reason asm/system.h is useful to aboot is because aboot is a bootloader, and that's not really the use case for linux-libc-dev. This is all in the Debian CVS repo now, and I've also uploaded a source package to <http://people.debian.org/~vorlon/aboot/>. > [1] Last time I checked, upstream no longer responded, but I still > have access to the sf repository, so including fixes upstream > could be possible :-)) It doesn't look like you're a project admin, though, so you can't grant anyone else access. Can you do file releases? It might be a good idea to have some sort of release tarball for aboot after the current round of clean-ups. My merge corresponds to what upstream labelled as version "1.0_pre20040408", but there was never a file release for it... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
