On Tue, Nov 8, 2011 at 6:28 AM, Ambrose, Martin <mar...@ti.com> wrote: > Hello. > > My goal is to get a baseline uClibc image for an arm architecture. > I've tried various mechanisms but eventually end up with build/run-time > errors. > > First attempt was to only use oe-core and specify the following in local.conf > TCLIBC = "uclibc"
generally above setting should only be what you need. e.g. $ TCLIBC=uclibc bitbake core-image-minimal > USE_NLS = "no" > USE_NLS_glib-2.0 = "no" > USE_NLS_glib-2.0-native = "yes" > USE_NLS_gcc-cross = "no" > > I try to build core-image-minimal but get an > armv5te-oe-linux-uclibceabi/glib-2.0-1_2.30.0-r2/glib-2.30.0 build error: > ./.libs/libglib-2.0.so: undefined reference to `qsort_r' uclibc does not have qsort_r implemented so I think glib is being built wrongly > > I'm surprised this is even trying to build given my settings in local.conf. > > Next I tried with the meta-micro layer and replace the above conf changes > with just > DISTRO= "micro-uclibc" > > Then build micro-base-image and get this packaging error > ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink > .so: uclibc-thread-db path \ > > '/work/armv5te-oe-linux-uclibceabi/uclibc-0.9.32-r4.3/packages-split/uclibc-thread-db/lib/libthread_db.so' this should be fixed seems like a bug in uclibc packaging > > I worked around this by overriding the OE packaging variables in local.conf > (moved dev-so). > WARN_QA = "ldflags useless-rpaths rpaths dev-so" > ERROR_QA = "debug-deps dev-deps debug-files arch la2 pkgconfig la > perms" > > Once built I get an immediate error on boot > /sbin/init: can't resolve symbol '__register_frame_info' > Kernel panic - not syncing: Attempted to kill init! > > I'm wondering if there is a simple mechanism to clean up the unwind bindings > via OE settings. > > In general, is there a "known-good" procedure for building/using uClibc via > oe-core +/- layers? oe-core should be able to build working images with uclibc for all supported architectures like eglibc however its not tested as much as eglibc images are. I will try to spin builds using uclibc and see how it goes. > > Regards, > Martin > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
