Buildroot wins over OpenEmbedded...
... at work. Or at least it looks that way.
Ok - not help required for code, but a natural result of coding...
We currently use CLFS, and talks have been going on about getting a replacement for building what is essentially a whole OS targeted at something that isn't what the system is built on.
Buildroot seems to be winning in the battle.
We were originally going to go for Yocto (openembedded based I understand,) but my impression is it was originally selected because 'shiney - must have' and another guy wasn't too impressed with an open-day/course about it.
OpenEmbedded itself was brought up as an alternative, but seems to be being dismissed because of the steep initial learning curve.
So Buildroot appears to be where we're going with this. The build itself isn't overly complicated, so we don't need too many bells and whistles, and everyone who'll be using whatever it is we end up using, is at least familiar with Linux.
In the hope that anyone here has used at least buildroot (and a bonus would be OpenEmbedded experience as well for someone who can compare the two,) am I coming up to a world of hurt, and any gotchas I should at least keep an eye out for?
Not sure if that may help...
We use Buildroot 2014.05 with gcc 4.7.3 and uclibc-0.9.33.2 for an ARM target.
For debugging purposes, I had to build every library with debug symbols. That worked fine, except for
uclibcwhich was still built without debug symbols and stripped before even being copied to the staging directory.
As it turns out, uclibc has its own build flags in its
.configwhich are not synchronized with Buildroot’s settings.
DOSTRIPin that file was not sufficient; it produced this:
LD libuClibc-0.9.33.2.so libc/libc_so.a(lockf.os): In function `__GI_lockf': .../build/uclibc-0.9.33.2/libc/misc/file/lockf.c:73: undefined reference to `_Unwind_Resume' libc/libc_so.a(lockf.os):(.ARM.extab+0x0): undefined reference to `__gcc_personality_v0' collect2: error: ld returned 1 exit status
This particular file apparently triggers a bug in GCC when built with no optimizations.
The solution I found was to patch
uclibc-0.9.33.2/libpthread/nptl/Makefile.inso it builds
lockf.cwith a non-null optimization level,
-CFLAGS-lockf.c = -fexceptions/CFLAGS-lockf.c = -fexceptions +CFLAGS-lockf.c = -fexceptions/CFLAGS-lockf.c = -fexceptions -O1
remove the offending
uclibc-0.9.33.2/libc/misc/file/lockf.osfile and run