1 |
I encountered the same error when building uclibc-0.9.28 using 'xmerge'. |
2 |
|
3 |
You're right, there should be some way to specify the kernel version for |
4 |
uclibc in the case that UTS_RELEASE isn't declared in |
5 |
include/linux/version.h |
6 |
|
7 |
Has there been any new development? |
8 |
|
9 |
~/Chris |
10 |
|
11 |
thomas.cooksey@××.com wrote: |
12 |
> I'm trying to use crossdev to generate a toolchain for an |
13 |
> arm-softfloat-linux-uclibc target. I'm using the following versions: |
14 |
> |
15 |
> binutils 2.17 |
16 |
> gcc 3.4.5 |
17 |
> kernel 2.6.18 |
18 |
> libc 0.9.28-r1 |
19 |
> |
20 |
> The command I'm using is: |
21 |
> |
22 |
> USE="-*" UCLIBC_CPU=ARM_XSCALE crossdev --binutils 2.17 --gcc 3.4.5 |
23 |
> --kernel 2.6.18 --libc 0.9.28-r1 --target arm-softfloat-linux-uclibc |
24 |
> |
25 |
> The build fails on uclibc at the point it runs the fix_includes.sh |
26 |
> script, which fails saying "Unable to determine version for kernel |
27 |
> headers". I've looked at the version.h in the |
28 |
> /usr/arm-softfloat-linux-uclibc/usr/include/linux directory and it is |
29 |
> indeed missing the UTS_RELEASE define. If you edit version.h and add |
30 |
> "#define UST_RELEASE "2.6.18foo"", the build runs through to the end |
31 |
> (although I've not had chance to test the binaries it outputs yet). |
32 |
> |
33 |
> Editing the version.h file by hand feels like a bit of a bodge. Is there |
34 |
> a fix for this? E.g. by adding a use flag I don't know about? |
35 |
> |
36 |
> |
37 |
> |
38 |
> Cheers, |
39 |
> |
40 |
> Tom |
41 |
> |
42 |
> |
43 |
> |
44 |
-- |
45 |
gentoo-embedded@g.o mailing list |