So the uClibc build script
(/var/tmp/portage/uclibc-0.9.28/work/uClibc-0.9.28/extra/scripts/fix_includes.sh)
tries to find UTS_RELEASE in include/linux/version.h
There are only 2 entries though,
#define LINUX_VERSION_CODE 132626
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
if you turn 132626 into hex it's 20612 ... does that correspond to 2.6.12 ?
My work-around was just to patch include/linux/version.h with
#define UTS_RELEASE "2.6.18"
However, in uClibc, the scripts should take into account the (newer?)
LINUX_VERSION_CODE field.
Has anyone filed this as a bug?
~/Chris
Christopher Friedt wrote:
I encountered the same error when building uclibc-0.9.28 using 'xmerge'.
You're right, there should be some way to specify the kernel version for
uclibc in the case that UTS_RELEASE isn't declared in
include/linux/version.h
Has there been any new development?
~/Chris
[EMAIL PROTECTED] wrote:
I'm trying to use crossdev to generate a toolchain for an
arm-softfloat-linux-uclibc target. I'm using the following versions:
binutils 2.17
gcc 3.4.5
kernel 2.6.18
libc 0.9.28-r1
The command I'm using is:
USE="-*" UCLIBC_CPU=ARM_XSCALE crossdev --binutils 2.17 --gcc 3.4.5
--kernel 2.6.18 --libc 0.9.28-r1 --target arm-softfloat-linux-uclibc
The build fails on uclibc at the point it runs the fix_includes.sh
script, which fails saying "Unable to determine version for kernel
headers". I've looked at the version.h in the
/usr/arm-softfloat-linux-uclibc/usr/include/linux directory and it is
indeed missing the UTS_RELEASE define. If you edit version.h and add
"#define UST_RELEASE "2.6.18foo"", the build runs through to the end
(although I've not had chance to test the binaries it outputs yet).
Editing the version.h file by hand feels like a bit of a bodge. Is there
a fix for this? E.g. by adding a use flag I don't know about?
Cheers,
Tom
--
gentoo-embedded@gentoo.org mailing list
