gcc-4.6 / bionic
 

On 04/05/11 16:15, Christopher Friedt wrote:
> bionic
> libc cross-toolchain


Apologies for my ignorances. This link went a long
way to present what is bionic libc:


http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html


cheers,
James

gcc-4.6 / bionic
 

Hi James,

On Tue, Apr 5, 2011 at 7:40 PM, wireless <wireless@tampabay.rr.com> wrote:
> Apologies for my ignorances. This link went a long
> way to present what is bionic libc:
>
> http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html

I've read that page too... not really sure what you're saying though.
You could say I'm leaning toward the "linux without politics" usage
model. It's straight-forward to patch bionic to use /etc/resolv.conf,
and add crypt routines as well as /etc/passwd & /etc/group usage. That
can be done with bsd licensed code.

BSD userland politics aside, I wonder what the typical steps would be
to 'port' gentoo over to a bionic-based libc. Something like the
following?

1) manually build a bionic cross-toolchain
2) do some basic verification with the cross-toolchain (static exe,
exe that uses .so, .so, etc)
3) build a native toolchain with the cross-toolchain, record build
steps / patches along the way
4) manually bootstrap gentoo natively, record build steps / patches
along the way
5) set up overlays: portage, crossdev, bionic, gcc, etc

C

gcc-4.6 / bionic
 

Hi James.... I liked reading your reply....

On Wed, Apr 6, 2011 at 9:45 AM, wireless <wireless@tampabay.rr.com> wrote:
> Ah grasshopper, you have *GROWN*! *I shall anticipate enjoying
> the stanza's of your music....

I don't know where you got the grasshopper bit from though... I've
been on this list for a looong time. I just choose not to talk much :)
Too many mailing lists... too little time!

Most of the embedded gentoo stuff I did was targeting armv4t, and the
company I did it for didn't actually sell devices, just services -
which meant that a lot of work I did wasn't legally required to be
made open-source. Thankfully, I no longer work for them and have much
better toys to play with now (e.g. beagle xM, panda, etc).

As for the BSD stuff, I agree. I think it's important to give back and
try to get bionic ELIBC to a somewhat stable level of support.
Naturally, that means being assigned bugs :P.

I would certainly be willing to 'own' some bugs within some reasonable
bounds (e.g. bionic's libstdc++ doesn't support exceptions... the
pthread lib doesn't support pthread_cancel). It's more or less
intended as a platform for managed code - .ie. Java. Although Python,
Mono, and Lua also work to some extent.

Linaro seems to want the bionic + gcc marriage to work too (i.e.
-mandroid), otherwise asac wouldn't have submitted patches for gcc.
Linaro has an army of engineers at their disposal and I would imagine
some of them probably use Gentoo too ;-)

C

gcc-4.6 / bionic
 

Also... an important couple of features:

TLS works on certain hardware (e.g. with hardware supported tls, like
armv7a), but not on all architectures, like in GNU [1], [2]. It's
probably better to blanket-disable this for now via a portage profile
variable.

SMP does not currently work OOTB. There are some patches floating
around[3], with issues that mainly lie outside of bionic, but I the
'official' SMP code will be available whenever Honeycomb is
released[4] ... which is of course whenever Google decides to do
release Honeycomb.

C

[1] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html#Thread-Local
[2] http://www.akkadia.org/drepper/tls.pdf
[3] http://groups.google.com/group/android-platform/browse_thread/thread/de20f1b10703acc2
[4] http://developer.android.com/sdk/android-3.0-highlights.html#multicore

gcc-4.6 / bionic
 

On 04/06/11 10:52, Christopher Friedt wrote:
> Also... an important couple of features:
>
> TLS works on certain hardware (e.g. with hardware supported tls, like
> armv7a), but not on all architectures, like in GNU [1], [2]. It's
> probably better to blanket-disable this for now via a portage profile
> variable.

TLS is very cool....
http://en.wikipedia.org/wiki/Wake-on-LAN
;-)


> SMP does not currently work OOTB. There are some patches floating
> around[3], with issues that mainly lie outside of bionic, but I the
> 'official' SMP code will be available whenever Honeycomb is
> released[4] ... which is of course whenever Google decides to do
> release Honeycomb.
>
> C
>
> [1] http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html#Thread-Local
> [2] http://www.akkadia.org/drepper/tls.pdf
> [3] http://groups.google.com/group/android-platform/browse_thread/thread/de20f1b10703acc2
> [4] http://developer.android.com/sdk/android-3.0-highlights.html#multicore

Thanks for all the wonderful links and information.
I'm too busy. You build some of this on a PANDA
board, drop me a line and I'll burn images and test
for you. ebtables and iptables in the image, would be
keen! My Panda is loanly just sitting in a box....
:-(


James

gcc-4.6 / bionic
 

On 04/06/11 10:30, Christopher Friedt wrote:

> I would certainly be willing to 'own' some bugs within some reasonable
> bounds (e.g. bionic's libstdc++ doesn't support exceptions... the
> pthread lib doesn't support pthread_cancel). It's more or less
> intended as a platform for managed code - .ie. Java. Although Python,
> Mono, and Lua also work to some extent.


I find your interests to be enlightening. Keep me posted
or updates to the list. You have to excuse my jaded prose,
too old and too callous sometimes, but, I do have the
very best of intentions......

> Linaro seems to want the bionic + gcc marriage to work too (i.e.
> -mandroid), otherwise asac wouldn't have submitted patches for gcc.
> Linaro has an army of engineers at their disposal and I would imagine
> some of them probably use Gentoo too ;-)

Ah, that seems to be an interesting lot, Linaro.

ORLANDO in October, 2011; sounds very interesting and doable....


https://wiki.linaro.org/Events/2011-10-LDS


James

gcc-4.6 / bionic
 

On Wednesday, April 06, 2011 09:45:50 wireless wrote:
> Now we only find
> http://www.rtems.com/
>
> Yet google is funding RTEMS for summer of code.......
> (Strange world, huh?)

not really. make a good/relevant open source project and you can apply to
google's SOC.
-mike

gcc-4.6 / bionic
 

On Tuesday, April 05, 2011 22:39:48 Christopher Friedt wrote:
> BSD userland politics aside, I wonder what the typical steps would be
> to 'port' gentoo over to a bionic-based libc. Something like the
> following?
>
> 1) manually build a bionic cross-toolchain
> 2) do some basic verification with the cross-toolchain (static exe,
> exe that uses .so, .so, etc)
> 3) build a native toolchain with the cross-toolchain, record build
> steps / patches along the way
> 4) manually bootstrap gentoo natively, record build steps / patches
> along the way
> 5) set up overlays: portage, crossdev, bionic, gcc, etc

put together an ebuild for bionic, add support to crossdev to mark *-bionic
targets to use the bionic ebuild, and that's about it.

you could add your own KEYWORD, but doesnt seem like it'd be worth it.

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.

so feel free to put together a bionic ebuild to get into the tree, and a
crossdev/toolchain.eclass patch should be trivial.
-mike

gcc-4.6 / bionic
 

On Wednesday, April 06, 2011 10:52:06 Christopher Friedt wrote:
> TLS works on certain hardware (e.g. with hardware supported tls, like
> armv7a), but not on all architectures, like in GNU [1], [2]. It's
> probably better to blanket-disable this for now via a portage profile
> variable.

any arch can do TLS. it's more a matter of defining the toolchain/C
library/kernel interfaces. the hardware only enters the picture in terms of
just how hard it actually is to make TLS work.

e.g. i386 could do TLS if people cared, but no one has bothered because i486
provides a few new atomic insns that makes the implementation a hell of a lot
simpler. so if no one actually cares about making it work on i386 procs, then
no one bothers.
-mike

gcc-4.6 / bionic
 

Hi Mike,

On Thu, Apr 7, 2011 at 12:43 AM, Mike Frysinger <vapier@gentoo.org> 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