8 Aug
2016
8 Aug
'16
9:44 p.m.
uclibc-ng & ARC developers:
I'm trying to use buildroot to build the latest ARC toolchain
(arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux
kernel. (Yes, it is an ancient kernel, but that's what I have to work
with for now, unfortunately.)
The buildroot config is:
BR2_arcle=y
BR2_arc750d=y
BR2_ENABLE_DEBUG=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_WCHAR=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_PTHREAD_DEBUG=y
BR2_TOOLCHAIN_BUILDROOT_USE_SSP=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_LOCAL=y
BR2_LINUX_KERNEL_CUSTOM_LOCAL_PATH="/path/to/vendor/2.6.35.12/kernel"
BR2_LINUX_KERNEL_VERSION="2.6.35.12"
With this setup, I'm running into various uclibc-ng 1.0.17 build errors:
1) ./include/sys/procfs.h:30:28: error: invalid application of
'sizeof' to incomplete type 'struct user_regs_struct'
#define ELF_NGREG (sizeof (struct user_regs_struct) / sizeof(elf_greg_t))
QUICK FIX:
Copied 'struct user_regs_struct' definition from corresponding
2.6.35.12 kernel header to libc/sysdeps/linux/arc/sys/user.h
2) ./include/sys/cachectl.h:13:26: fatal error: asm/cachectl.h: No
such file or directory
#include <asm/cachectl.h>
QUICK FIX:
Commented the above line out in libc/sysdeps/linux/arc/sys/cachectl.h
3) In file included from
.../buildroot/output/build/linux-headers-custom/usr/include/linux/posix_types.h:47:0,
from
.../buildroot/output/build/linux-headers-custom/usr/include/linux/types.h:8,
from
.../buildroot/output/build/linux-headers-custom/usr/include/linux/rtnetlink.h:4,
from libc/inet/netlinkaccess.h:26,
from libc/inet/ifaddrs.c:36:
.../buildroot/output/build/linux-headers-custom/usr/include/asm/posix_types.h:22:25:
error: conflicting types for '__kernel_mode_t'
typedef unsigned short __kernel_mode_t;
^
In file included from ./include/bits/types.h:30:0,
from ./include/sys/types.h:30,
from ./include/sys/uio.h:23,
from ./include/sys/socket.h:27,
from ./include/ifaddrs.h:23,
from libc/inet/ifaddrs.c:22:
./include/bits/kernel_types.h:25:23: note: previous declaration of
'__kernel_mode_t' was here
typedef unsigned int __kernel_mode_t;
^
QUICK FIX:
Added #include <asm/posix_types.h> on top of
libc/sysdeps/linux/arc/bits/kernel_types.h and wrapped the uclibc
definitions with #ifndef _ASM_ARC_POSIX_TYPES_H ... #define
_ASM_ARC_POSIX_TYPES_H ... #endif to match the kernel header wrappers.
Also, needed to add #ifndef ... #define ... #endif wraps to __FD_*
definitions in libc/sysdeps/linux/common/bits/select.h
4) /usr/bin/make -j1 -C .../buildroot/output/build/uclibc-1.0.17
CC=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-gcc"
CPP=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-cpp"
LD=".../buildroot/output/host/usr/bin/arc-buildroot-linux-uclibc-ld"
ARCH="arc" PREFIX=.../buildroot/output/target utils install_utils
make[3]: Nothing to be done for `locale_headers'.
CC utils/getconf
../lib/libc.so.1: undefined reference to `__xstat32_conv'
../lib/libc.so.1: undefined reference to `__xstat64_conv'
collect2: error: ld returned 1 exit status
make[3]: *** [../utils/getconf] Error 1
make[2]: *** [utils] Error 2
make[1]: ***
[/usr/local/google/home/pgynther/clients/buildroot/output/build/uclibc-1.0.17/.stamp_target_installed]
Error 2
make: *** [_all] Error 2
QUICK FIX:
Created libc/sysdeps/linux/arc/bits/kernel_stat.h file from
corresponding kernel definitions and also added 'select
ARCH_HAS_DEPRECATED_SYSCALLS' in extra/Configs/Config.arc
After the above 4 patches have been applied, buildroot is able to
build the toolchain successfully.
And then, using this new toolchain, I'm able to build our internal
2.6.35.12 kernel + initramfs image.
However:
Once I boot the newly built image, the kernel boots fine, but /init
(busybox) crashes every time. And same happens with /bin/sh (dash).
Basically, no userland binary built with this toolchain runs on top of
2.6.35.12 kernel.
No matter what I provide on kernel command line parameter
"rdinit=/path/to/binary", the boot always ends with "Attempted to kill
init!" because the kernel doesn't like the userland binaries.
[ 2.070000] TCP cubic registered
[ 2.075000] NET: Registered protocol family 10
[ 2.080000] NET: Registered protocol family 17
[ 2.085000] 802.1Q VLAN Support v1.8 Ben Greear <greearb(a)candelatech.com>
[ 2.090000] All bugs added by David S. Miller <davem(a)redhat.com>
[ 2.100000] Freeing unused kernel memory: 19904k freed [84938000]
TO [85ca8000]
[ 2.105000] Common mmap addr-space starts 2c0f0000
[ 2.115000] Kernel panic - not syncing: Attempted to kill init!
Questions:
1) Does the latest ARC toolchain use some new ABI for binaries that
makes them incompatible with 2.6.35.12 kernel?
2) Is uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel headers?
Any help is greatly appreciated. Thanks.
-- Petri
8 Aug
8 Aug
10:08 p.m.
New subject: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
On 08/08/2016 02:44 PM, Petri Gynther wrote:
uclibc-ng & ARC developers:
I'm trying to use buildroot to build the latest ARC toolchain
(arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux
kernel. (Yes, it is an ancient kernel, but that's what I have to work
with for now, unfortunately.)
...
Questions:
1) Does the latest ARC toolchain use some new ABI for binaries that
makes them incompatible with 2.6.35.12 kernel?
Indeed even if you were to build it successfully - you will run into ABI issues -
2.6.35 is ABI v1 and we are currently at v3 (which is going to change soon even
further to v4 - for ARC HS processors)
More details at:
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linu…
2) Is uclibc-ng 1.0.17 supposed to be compatible with
2.6.x kernel headers?
No - modern/upstream uClibc-ng is not compatible with 2.6.35
You need to use the uClibc of the time - with pairing gcc/binutils - although that
will be a can of worms
Any help is greatly appreciated. Thanks.
Sorry - can't help you much here !
-Vineet
10 Aug
10 Aug
5:03 p.m.
New subject: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
Hi,
Vineet Gupta wrote,
On 08/08/2016 02:44 PM, Petri Gynther wrote:
This is only the case for ARC, right?
Other architectures should work fine, like MIPS or ARM.
best regards
Waldemar
uclibc-ng & ARC developers:
I'm trying to use buildroot to build the latest ARC toolchain
(arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux
kernel. (Yes, it is an ancient kernel, but that's what I have to work
with for now, unfortunately.)
...
Questions:
1) Does the latest ARC toolchain use some new ABI for binaries that
makes them incompatible with 2.6.35.12 kernel?
Indeed even if you were to build it successfully - you will run into ABI issues -
2.6.35 is ABI v1 and we are currently at v3 (which is going to change soon even
further to v4 - for ARC HS processors)
More details at:
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linu…
2) Is uclibc-ng 1.0.17 supposed to be compatible
with 2.6.x kernel headers?
No - modern/upstream uClibc-ng is not compatible with 2.6.35
You need to use the uClibc of the time - with pairing gcc/binutils - although that
will be a can of worms
5:22 p.m.
New subject: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
On 08/10/2016 10:03 AM, Waldemar Brodkorb wrote:
Perhaps they will - I'm not sure. ARC certainly has issues due to the syscall ABI
change from 2.6.35 to upstream 3.8 !
-Vineet
> 2) Is
uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel headers?
>
> No - modern/upstream uClibc-ng is not compatible with 2.6.35
> You need to use the uClibc of the time - with pairing gcc/binutils - although that
> will be a can of worms
This is only the case for ARC, right?
Other architectures should work fine, like MIPS or ARM. 
11 Aug
11 Aug
5:48 a.m.
New subject: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers
Hi Waldemar,
On Wed, 2016-08-10 at 19:03 +0200, Waldemar Brodkorb wrote:
Hi,
Vineet Gupta wrote,
As Vineet mentioned above that's the case for ARC because of ABI changes, see
Wiki page above.
As for arches that were supported in Linux for much longer time like ARM and MISP most
probably up-to-date uClibc would work with 2.6.x kernels but frankly I haven't tried
that
myself.
Still newer arches like Nios and Extensa may have similar issues as we have.
But again I barely have any experience with those arches so asking their maintainers
might be a good idea.
-Alexey
On 08/08/2016 02:44 PM, Petri Gynther wrote:
This is only the case for ARC, right?
Other architectures should work fine, like MIPS or ARM.
uclibc-ng & ARC developers:
I'm trying to use buildroot to build the latest ARC toolchain
(arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux
kernel. (Yes, it is an ancient kernel, but that's what I have to work
with for now, unfortunately.)
...
Questions:
1) Does the latest ARC toolchain use some new ABI for binaries that
makes them incompatible with 2.6.35.12 kernel?
Indeed even if you were to build it successfully - you will run into ABI issues -
2.6.35 is ABI v1 and we are currently at v3 (which is going to change soon even
further to v4 - for ARC HS processors)
More details at:
https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linu…
2) Is uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel headers?
No - modern/upstream uClibc-ng is not compatible with 2.6.35
You need to use the uClibc of the time - with pairing gcc/binutils - although that
will be a can of worms
2821
days inactive
2824
days old
4 comments
4 participants
participants (4)
-
Alexey Brodkin -
Petri Gynther -
Vineet Gupta -
Waldemar Brodkorb