Mailing List Archive

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

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

On 04/05/11 22:39, Christopher Friedt wrote:
> 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.

I'm not up to speed on Android et. al......

I do like the "smallness" of what bionic purports to do. Linux
(kernel, kde/gnome, etc etc) are well on the way to IBM/doz
bloat-wear, imho. So I do anticipate a return to the basics,
(aka smallness).....


> 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.

Folks should be aware of licenses and choose according to their goals
and needs. I've got "no religion" when it comes to licenses. Personally
I wish all licenses, patents and politics would just go away...
After all, they are just *noise* imho. But noise is a fact of
life so we must deal with it, each in our own (best) way.


> 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?

BSD has a fundamental flaw, imho. Once you free up the license
restrictions, much of what is innovated is rarely shared to put back
into the community. I understand folks need to make a few dollars, as a
corporation some of that is necessary, but the not contributing back
snobbishness of BSD is a long, jaded history (Eric and Sendmail as an
example).

Want another example? OK OAR (was a .org) was a technical governmental
body that developed RTEMS:

http://en.wikipedia.org/wiki/RTEMS

Now we only find
http://www.rtems.com/

Yet google is funding RTEMS for summer of code.......
(Strange world, huh?) If you know any college kids
with your tendencies, then SOC at RTEMS would be
keen. Suggest a port/marriage to embedded Gentoo.
Make yourself *famous*!


The NSA actually funded openbsd for a while and still finds "the rat"
to be quite brilliant and entertaining......

http://boingboing.net/2010/12/15/rumors-of-an-fbi-bac.html


Personally,
I do not find the "spoofs" to be threatening at all; it's the
politicians with dark_commercial_threads that worry me; a bunch
of "stupid_whores" that are in charge of decision making? Then when
they do reach out to someone technical, it's some old (technically
famous) fart that is useless and has lost his/her salt! They quickly
sell out for a few dollars because they are getting old and worry
about retirement and what others think about them.

America, has few young lions any more, because our judicially
dominatrix leadership is pushing agendas where young lions are quickly
neutered and marginalized, again and again and again, imho.

What BSD needs is for the government (US) to fund research and
development and support for BSD, much like google funds Linux
via the Summer of Code. But as soon as they appoint some tainted
agency, with dark connections to the commercial world, much get's
tainted, imho. A young lion needs to emerge.

After all BSD is American, from Berkeley (bunch of hippies)
and there are lots of brilliant, unemployed college kids floating
around.....(certainly not fact, just my opinion). So that's why I
left BSD for Linux; more sharing, support and friendship; Some would
say that sense of "community" is because of the gpl licenses.....


> 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


Ah grasshopper, you have *GROWN*! I shall anticipate enjoying
the stanza's of your music....


peace,
James

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

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

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

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

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

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

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

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

On Thu, Apr 7, 2011 at 7:56 AM, Christopher Friedt wrote:
> On Thu, Apr 7, 2011 at 12:43 AM, Mike Frysinger 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.

feel free to post to the list once you've got that

>> 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.

that makes sense ... maybe profiles/embedded/bionic/ ...

> So are there no other hidden gems that pivot on ELIBC?

not really. just make sure you add it to profiles/desc/elibc.desc.
-mike

Hrrmm... gnuconfig has alreaded added linux-android* upstream for
their system types in config.sub but using 'android' as a descriptor
for the libc really wouldn't make sense if it wasn't an Android
system.

It would probably be prudent to add linux-android* | linux-bionic* ...
there are a few significant differences. I guess the main
differentiators would be FHS (android prefixes everything with
/system), support for /etc/passwd, /etc/group, /etc/resolv.conf,
crypt(3), getpwnam(3), getgrnam(3), and essentially any other missing
feature that people might want to add in the future.

They also don't have an entry in config.guess for LIBC=android (or
LIBC=bionic). Something like this would work.

...
# ifdef __BIONIC__
# ifdef __ANDROID__
LIBC=android
# else
LIBC=bionic
# endif
# else
LIBC=gnu
# endif
...

I'll add a gnuconfig revision with those changes in my overlay.

To me, it just makes sense to differentiate this way... of should
still be possible to build an Android toolchain, so I'll add
IUSE=android to the bionic ebuild. The bionic ebuild is otherwise
done, but I still have to add something for
crosscompile_opts_headers-only before it works with crossdev.

Cheers,

C

On Sunday, April 10, 2011 09:43:09 Christopher Friedt wrote:
> Hrrmm... gnuconfig has alreaded added linux-android* upstream for
> their system types in config.sub but using 'android' as a descriptor
> for the libc really wouldn't make sense if it wasn't an Android
> system.

if that's the way upstream gnuconfig/gcc has gone, then it doesnt make much
sense to try and fight the tide. it's just a name.
-mike

On Sun, Apr 10, 2011 at 12:39 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> if that's the way upstream gnuconfig/gcc has gone, then it doesnt make much
> sense to try and fight the tide.  it's just a name.

Meh, I'm not really focusing on the 'Android' userspace right now
anyway, but the patches were easy enough. My bionic ebuild currently
does not distinguish between -android* and -bionic*. I'm mainly
interested in getting a Gentoo userspace up and running in any case.

I just successfully got a gcc / bionic cross-toolchain built with
crossdev (no c++ yet). x86_64-pc-linux-gnu -> x86_64-pc-linux-bionic.
The toolchain is okay aside from linking. It's still looking for the
glibc-type crt files. For bionic they're named differently and there
isn't an exact 1-1 mapping: crtend_android.o, crtbegin_so.o,
crtend_so.o, crtbegin_static.o. It would be nice.

Also, my bionic ebuild currently leverages the Android build system
heavily, which I would prefer _not_ to do, but it seems
counter-productive right now to reinvent the wheel with autotools.
(volunteers?)

Is anyone interested in having a look yet? I guess I could post it on
gitorious as a layman overlay.

Cheers,

C

On Mon, Apr 11, 2011 at 5:11 PM, Christopher Friedt
<chrisfriedt@gmail.com> wrote:
> crtend_so.o, crtbegin_static.o. It would be nice.

That should read "it would be nice to have linking work before it
really goes public."

On Tue, 12 Apr 2011 00:11:04 +0300, Christopher Friedt
<chrisfriedt@gmail.com> wrote:
> Is anyone interested in having a look yet? I guess I could post it on
> gitorious as a layman overlay.

What is the (long-term) technical advantage to use bionic, compared to
glibc and uclibc?

On 11/04/2011 23:52, Arkadi Shishlov wrote:
> On Tue, 12 Apr 2011 00:11:04 +0300, Christopher Friedt
> <chrisfriedt@gmail.com> wrote:
>> Is anyone interested in having a look yet? I guess I could post it on
>> gitorious as a layman overlay.
>
> What is the (long-term) technical advantage to use bionic, compared to
> glibc and uclibc?
>

I would like to hear some answers also. Google's top hit is:

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

That's some years out of date and can be summarised as: advantage is a
bsd licence versus an lgpl licence. Also some speedup due to dropping
support for c++ exceptions. Also in 2008 there was no TLS in uclibc
(seems quite mature at least in current uclibc git)


This does raise a good point - can "we" really work on getting uclibc
next release out and stabilised as quickly as possible? It's a massive
improvement over prior releases and even the unreleased git should
become everyone's version of choice right now (for a certain definition
of everyone). On x86 a very large proportion of software now compiles
without obvious problems

I'm using a trivial bump of the in tree ebuild to grab the current git
uclibc and very pleased with it


Cheers

Ed W

On Mon, Apr 11, 2011 at 6:52 PM, Arkadi Shishlov
<arkadi.shishlov@gmail.com> wrote:
> What is the (long-term) technical advantage to use bionic, compared to glibc
> and uclibc?

There really is little technical advantage over glibc or uclibc. Most
would probably argue the opposite. For most embedded applications, I
would actually suggest using uclibc instead of bionic.

The (short- and long-term) advantage really just lies in the license.

I should have linking done pretty soon - it was already there afaict,
but just needed to '--with-bionic' configuration option to work.

When finished, I'll put up a layman overlay on gitorious.

For now, I'm only going to be testing this on the following crossdev
configurations:

x86_64-pc-linux-gnu <===> x86_64-pc-linux-bionic
x86_64-pc-linux-gnu <===> arm-softfloat-linux-bioniceabi

Be warned: I might not finish it tonight because the Canadian
political leaders debate is on TV and I take a keen interest ;-)

Cheers,

C

On Tue, Apr 12, 2011 at 8:52 AM, Ed W <lists@wildgooses.com> wrote:
> I would like to hear some answers also.  Google's top hit is:

This is probably more interesting to you (and was linked from the page
you cited)

http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/docs/OVERVIEW.TXT

Yar!

I feel like such a pirate right now ;-)

Crossdev succeeds for x86_64-pc-linux-gnu to x86_64-pc-linux-bionic.
After this, I'll probably be working on a cross-armv7a version to
support e.g. the BeagleBoard. Next, will probably be the PandaBoard
once the Android developers release their SMP code with Honeycomb. I
also just read that Intel is pushing for an Android-based tablet to be
released [1]. The article is speculative, but it isn't the only one
speculating. If this is true, it would mean Bionic (Honeycomb or
Iced-cream) will probably have better support for x86* from the
get-go.

Currently ironing out a couple of bugs with cross-compiling busybox.
It's mainly just a few kernel headers missing, which I presume will be
the main source of 'bugs'. Adding missing kernel headers is a bit of a
process because it requires running them through the
bionic/libc/kernel/tools/clean_header.py script [2]. I have actually
created a seperate ebuild for sys-kernel/bionic-kernel-headers due to
the recent kerfuffle about licensing [3]. So rather than use the stock
sys-kernel/linux-headers, I'm using the 'cleansed' versions that come
with the bionic libc.

I figure that it will be safe to release an overlay once at least one
arch is ~, busybox compiles without too much complaining, and I have a
qemu image / build instructions to distribute.

Would love to have some people willing to try building for other
arches at that point. Currently, it looks like x86*, arm and sh will
work 'out of the box' (not really OOTB, but supported with bionic
kernel headers). However, there are libm headers for mips, ppc and
sparc64 as well.

Cheers,

C

[1] http://www.digitimes.com/news/a20110413PD223.html
[2] http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=libc/kernel/tools/clean_header.py
[3] http://lwn.net/Articles/434318/

On 04/15/11 08:42, Christopher Friedt wrote:
> Yar!
>
> I feel like such a pirate right now ;-)
>
> Crossdev succeeds for x86_64-pc-linux-gnu to x86_64-pc-linux-bionic.
> After this, I'll probably be working on a cross-armv7a version to
> support e.g. the BeagleBoard. Next, will probably be the PandaBoard
> once the Android developers release their SMP code with Honeycomb. I
> also just read that Intel is pushing for an Android-based tablet to be
> released [1].

Hello Christopher,

Thanks for the update on your progress. I ran across this interesting
article, where Google is trying to influence ARM offering and more
on licensing:

http://www.eetimes.com/electronics-news/4214648/Reports--Google-could-standardize-Android-on-ARM-


enjoy,
James

Apparently it is now official [1] and there will be many.

On Fri, Apr 15, 2011 at 8:42 AM, Christopher Friedt
<chrisfriedt@gmail.com> wrote:
> also just read that Intel is pushing for an Android-based tablet to be

[1] http://www.pcworld.com/article/224835/intels_oak_trail_tablets_to_get_googles_android_30.html