Building an arm/android toolchain

[i92guboj]

This post was about getting an arm uclibc toolchain, but the goal of it has greatly changed, so, please, don't be scared if the contents of the first posts doesn't exactly match the new title

Hello.


I've been toying lately with android phones. All is going as smooth as it could be. Up to now I've been able to compile my own kernels and some basic packages using an arm-gentoo-linux-gnueabi toolchain, without much problems.

However, I wanted to create an uclibc based toolchain, just for the sake of experimenting. It seems however that this is a completely different beast. I've tried many combos, amongst them, the one that's listed in the gentoo crossdev guide. I've also tried many gcc versions that range from 3.4 to 4.7. They all fail to build one or another component of the toolchain with different errors. Right now, I am trying to build arm-softfloat-linux-uclibc, but anything ending in -uclibc has failed, at least for now.

Does anyone have a viable set of packages to build a uclibc based toolchain that will work?

Bear in mind that I am new to the arm architecture, and I haven't ever used uclibc.

[i92guboj]

As it often happens, all you have to do to find the solution is to ask in a forum. Five minutes after that you'll find for yourself what you haven't found in days of research

[bixmix]

Not sure if you saw my post or not.

I think it's worth mentioning that uclibc is the old ABI or OABI. This caused me considerable confusion until I ended up doing some googling.

Most people are going to want to use uclibceabi which uses the new(er) EABI. OABI is deprecated and while be made obsolete when the next major version of gcc rolls around. EABI generally doesn't error out on you like uclibc will.

In general, you probably want to specify softfloat or hardfloat for your second tuple:

arm-softfloat-linux-uclibceabi
arm-hardfloat-linux-uclibceabi

I think for a standard android, you'll probably want a hardfloat.

[i92guboj]

I did (see your post). It was for sure helpful to an extent, since I am a newcomer to arm, and I can learn from virtually anything at this stage

However, since your thread was about retaining compatibility with OABI existing binaries, I thought that I'd better open a new thread for my specific needs, rather than hijacking yours.

One of the problems I am facing is identifying the capabilities of my device. In a pc we just cat /proc/cpuinfo, and all you need is there. In arm, I am not that sure, since there seems to be lots of -march, -mcpu and -mtune options, and the gcc man page doesn't offer any help for them, other than just listing them, which means nothing to me (it does ok with x86 and x86_64 flags, but not with arm ones).

But that's another story that I'll eventually figure out, when I have the time to read everything I bookmarked

Thank you for the info

[bixmix]

Well Android is technically an OS / platform as opposed to a specific hardware architecture. You would need to know what ARM core the manufacturer of your device chose for its hardware architecture.

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

From there you can start using march and mtune.

For example, I know that what I was using was an ARM926EJ-S based on some of the documentation I received for my product.

In general, GCC's march and mtune options are going to match up to the list in the wikipedia link where march is equivalent to "ARM Architecture" and mtune is equivalent to "ARM Core". This doesn't match up exactly. For mine you'll note that the architecture is techincally armv5tej, but gcc doesn't actually know what an armv5tej is. In reality, the j means that java can be executed directly on the processor core. So technically, gcc just doesn't need to distinguish between armv5te and armv5tej. And that's what you'll find my options ended up being: march=armv5te and mtune=arm926ej-s.

I found this page helpful for gcc:
http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

There was also a pdf I downloaded at some point that expanded upon the above list, but I can't find that link at the moment.


In addition to GCC, there's a way to tune uclibc using the environment variable, UCLIBC_CPU. In my case, I already knew that I had an ARM926EJ-S. The closest matchup for my processor with the UCLIBC_CPU options was: ARM926T.

The reality is that the march, mtune and UCLIBC_CPU is not 100% necessary, but it can lead to a performance boost over the generic options so you'll want to figure out what you're really using and build for that architecture.

[i92guboj]

I was researching along those same lines. I figured out for myself what the "J" stands for, and I decided to park for now the UCLIBC_CPU thing, and see if, before worrying about that, I can get a toolchain that will produce usable binaries for my platform.

After some tries, I have built two toolchains for testing, which are

• arm-gentoo-linux-gnueabi
  
• arm-hardfloat-linux-uclibceabi

Static binaries do work. I can compile anything with either of them, and it will work in my phone. At least, busybox which was my main concern do work. Nano does as well, though it has other issues to deal with at a later stage. But the binaries do work.

----

However, I haven't managed to get to work dynamically linked bins. After all, if the device has a /system/lib I think I should be taking advantage of that and not duplicating object code everywhere. I think that there's either something wrong I am doing or something that's fundamentally wrong in the way that gentoo/crossdev/emerge-wrapper handle this stuff.

Example given. I compile busybox dynamically with USE=-static (besides that, my savedconfig in /etc/portage/savedconfig/sys-apps/busybox-<version> is set to compile non-statically. I use for that the emerge wrapper this way:

[ssvb]

Is your android phone using uclibc?

[i92guboj]

[ssvb]

Android is using bionic: http://en.wikipedia.org/wiki/Bionic_%28software%29
I suggest you to try NDK and build "standalone toolchain" for the start: http://developer.android.com/sdk/ndk/index.html
Not sure what is the android support status in gentoo toolchain and crossdev, but fsf gcc supports android since 4.6: http://gcc.gnu.org/gcc-4.6/changes.html

[bixmix]

For better or for worse, ldd must be run on the device. I couldn't tell if you were running file on the device or on your pc.

I think the header information is useful for determining whether or not you're using the right OS/ABI, endian, machine type, etc. When you get these all right, then it's likely your binaries (when statically linked) are going to work on your device. And I think you had success there, so I won't talk more about that.

I think ssvb's suggestion is going to get you to a working binary faster than if you did trial and error on your own. To dynamically link, it's really important you're using the same toolchain to build the libraries in addition to using the same library versions. You could spend weeks just trying to match up the toolchain, toolchain options and library files with a working gentoo toolchain.

Even if you want a gentoo toolchain, I think understanding the libraries and toolchain that is used is going to help you match up what you need on the gentoo side. To get a working gentoo toolchain, you would likely need to patch crossdev for a third option of libc: bionic.

It does look like someone else has started here: http://code.google.com/p/gentoo-bionic/

Also, if you get a chance, maybe change the title of this discussion to include Android since that will make it more relevant to people searching through the forums.

[i92guboj]

Indeed, I succeeded (easily, I might add) to produce static binaries that work on the device.

I didn't know about bionic, however, which is probably why I haven't produced yet a single dynamic binary that will work on this machine. I noted your pointers down, and I am going to carefully re-do all this. This time I should be taking a better direction

I'll of course edit the title as well.

[i92guboj]

[i92guboj]

I managed to compile ncurses by adjusting some options and witg a trivial patch to it, but i'm stuck with nano. It compiles but can't link due to getpwent and a coupke other libc funcs not being there.

I wonder if this could be solved by compiling my own bionic, or if it simpky lacks this funcs. I guess it's time to look at that overlay and see if it does something special to get nano to compile.

[turtles]

Did you ever get http://code.google.com/p/gentoo-bionic/ working and build Nano?
(I just got tossed into the android pond)
Cheers
_________________
Donate to Gentoo

[i92guboj]

No. But to tell the truth I didn't try hard. I was sucessful at building dynamic bins however, with a crossdev toolchain.

[lost+found]

I wonder, if there's any progress in dynamically linking Bionic. Success stories, for instance. Which Gentoo packages will compile and run on an Android device?

[i92guboj]

[lost+found]

@i92guboj

Thanks for explaining this. It's clear to me now, that it's not worth the time. Building small static applications for Android, to get a task done, is good enough though. I would love to replace Android by Plasma Active anyway. The community better focus on those kind of projects.

[cwr]

I've been cross-compiling a fair bit of stuff for arm7a (a BeagleBone Black, which can run a
version of Android BTW). Most things seem to build, given the correct environment; some bits
I native-compiled simply because I couldn't be bothered to work out why emerge was failing.

I never had to patch anything.

Will

(Building a cross-compiler with crossdev is really a question of selecting the right components;
for some reason a number of GCC versions just won't buld. It was the same with AVR, when
I built that cross-compiler a while back. I think you need GCC 4.7.x to build correctly for ARM.)

[i92guboj]