| Summary: | Cannot compile gcc without threads (uClibc-based) | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Adam Nielsen <a.nielsen> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | minor | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2012.08 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
buildroot config to generate error
uClibc config, generated through buildroot |
||
|
Description
Adam Nielsen
2013-05-04 05:12:02 UTC
Created attachment 4880 [details]
uClibc config, generated through buildroot
Add uClibc config for MMU-less with no thread support
I tried reproducing the problem, and get failures in uclibc, even with your proposed .config:
In file included from libpthread/nptl/sysdeps/unix/sysv/linux/arm/fork.c:31:0:
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:61:17: error: 'fork' undeclared here (not in a function)
extern __typeof(fork) __libc_fork;
^
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:63:1: error: '__libc_fork' redeclared as different kind of symbol
__libc_fork (void)
^
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:61:23: note: previous declaration of '__libc_fork' was here
extern __typeof(fork) __libc_fork;
^
In file included from ./include/tls.h:6:0,
from libpthread/nptl/sysdeps/unix/sysv/linux/arm/fork.c:23:
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c: In function '__libc_fork':
./libpthread/nptl/sysdeps/arm/tls.h:114:11: warning: implicit declaration of function '__builtin_thread_pointer' [-Wimplicit-function-declaration]
((struct pthread *)__builtin_thread_pointer () - 1)
^
./include/bits/stdio-lock.h:42:22: note: in expansion of macro 'THREAD_SELF'
void *__meself = THREAD_SELF; \
^
./include/bits/uClibc_mutex.h:96:50: note: in expansion of macro '_IO_lock_lock'
#define __UCLIBC_IO_MUTEX_LOCK_CANCEL_UNSAFE(M) _IO_lock_lock(M)
^
libpthread/nptl/sysdeps/unix/sysv/linux/arm/../fork.c:127:3: note: in expansion of macro '__UCLIBC_IO_MUTEX_LOCK_CANCEL_UNSAFE'
__UCLIBC_IO_MUTEX_LOCK_CANCEL_UNSAFE(_stdio_openlist_add_lock);
^
In any case, something is definitely broken here...
ARM nommu support is broken in general, there are several toolchain component version restrictions that are currently unaccounted for. Not only that but the toolchain build rules aren't properly done (the tuple is wrong for example). The problem is that Qemu doesn't emulate any usable (uc)linux hardware to test with, and probably the most experienced devels who can help with this lack any real nommu hardware that's tested with uclinux as a starting point. Also it's probably more useful to work on modern ARM nommu support (Cortex M series) but in general from some quick investigations i've done it's mostly stuck with an oldish and heavily tweaked 2.6.33ish kernel. So for ARM7TDMI who knows which kernel works properly. I recently got my hand on an EFM32 development board, which has a Cortex-M3 capable of running a mainline Linux kernel. Using this, I'm hoping to progressively improve the support for ARM noMMU in Buildroot. Probably a topic for the next release cycle, though. Support for ARM(7TDMI/720T/740T) has been dropped from buildroot with commit http://git.buildroot.org/buildroot/commit/?id=befab216a29927f598e0a3ba0b012f7e822bb235 Commit message is: " arch/arm: drop ARM(7TDMI/720T/740T) support The toolchain currently doesn't build for nommu ARM and is in need of serious work. Problem is there are no emulation targets and real ARM(7TDMI/720T/740T) hardware that's capable of running linux (enough memory, having a memory controller...) is VERY rare and uses very old versions to make it usable. The ARM nommu focus should go into Cortex M series processors that are obtainable at reasonable cost on modern hardware that has external memory controllers. " |