Hi Mike, On Thu, Apr 7, 2011 at 12:43 AM, Mike Frysinger <[email protected]> wrote: > On Tuesday, April 05, 2011 22:39:48 Christopher Friedt wrote: > put together an ebuild for bionic, add support to crossdev to mark *-bionic > targets to use the bionic ebuild, and that's about it.
I already added the relevent bits to crossdev, and I'm still putting together a bionic ebuild. I'll probably modify the gcc-4.6.0 ebuild as well and some logic for ELIBC=bionic. Re: the TLS sections... yea, it wasn't really planned for in advance by the bionic devs so it isn't really integrated into the toolchain/libc and does require hw support. http://marc.info/?l=linux-omap&m=120384694214686&w=2 > you could add your own KEYWORD, but doesnt seem like it'd be worth it. definitely not, but I might need to add some rules in /usr/portage/profiles to mask certain flags / packages. > as for the rest, considering the fundamental limitations they've added to > bionic (limited libpthreads/libm/etc...), i dont think a "full" blown port > makes much sense. bionic is a toy libc meant for one thing -- get a java vm > running on top of it. if you want a "real" embedded Linux system, uClibc > makes a hell of a lot more sense. Exactly - it is more or less a toy libc for managed code running atop... but considering that the current alternative to build libs for Android is to use the NDK or multi-gigabyte build tree (i.e. Android.mk), portage seems a _lot_ more appealing. A good example is my port of liboctave to Android. I built uclibc++ for all of the c++ features android didn't support, hacked a fortran compiler into Android's build system for blas, lapack, and a lot more... it was fugly. > so feel free to put together a bionic ebuild to get into the tree, and a > crossdev/toolchain.eclass patch should be trivial. I will Thanks for the input. So are there no other hidden gems that pivot on ELIBC? Cheers, C
