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. _________________Gentoo Handbook | My website

Last edited by i92guboj on Thu Jun 07, 2012 4:39 pm; edited 1 time in total

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:

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

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.

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.

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:

It seems to be somehow linking to things it shouldn't be linking. There's not even a libgcc_s.so.1 in my SYSROOT at all.

Code:

find /usr/arm-gentoo-linux-gnueabi/ -name libgcc_s.so.1

That reports nothing, of course. So, it must be linking (don't ask me why) to the real root libgcc.so.1.

arm-hardfloat-linux-uclibceabi also links the binary to this. This file is not available in that SYSROOT either, and of course, it's not available in my device either.

I am more thinking aloud than asking for help, I will eventually figure out what's wrong, or simply discard all this Gentoo crossdev stuff which seems to bring more problems than goodness, and roll my own.

All I know is it has a libc.so file. In any case, I have built both toolchains just to experiment. Neither of them work, both of them have the same problems with dynamic bins. And static binaries produced with either of them will work in the device. So, at this point, that's not my main concern.

However, tips on discovering that this libc.so file is are welcome.

Right now, the headers for bins produced by the gnueabi and uclibceabi toolchains seems to be the same, at least from what I can tell from the readelf output, but, again, I know nothing about uclibc. In any case, I am not sure that the uclibc toolchain is producing uclibc bins at all, as I suggested above.

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.

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

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.

I don't really care about that. As long as the toolchain works.

I've managed to compile a dynamically linked version of busybox. However, I am starting to see that this isn't going to be an easy walk. Busybox brings a number of default configs that are known to work with the android toolchain, but any deviation from that will probably end with compilation failures. I guess the same will be true for most software, so if this is not able to produce working binaries for everything I want I might end compiling regular gnueabi static bins. I'll see as I go. I can do some patching on my own, but only to an extent. _________________Gentoo Handbook | My website

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._________________Gentoo Handbook | My website

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?

I've been busy with other real life issues.

But there are fundamental problems here. A lot of patching (even if minor) is needed here and there to get even the most basic stuff running. Take something simple as nano, for example. One of its dependencies (which is also a dependency in a direct or indirect manner for about 99% of the open source user land programs) is ncurses. And, ncurses will fail to cross-compile in anything that's not a current gnu toolchain with a *nix-like fs layout. I've had problems to build it in android, but also in cygwin, mingw32 and some other atypical scenarios.

If I ever get my hands back on this (first I have to deal with a lot of work in other areas) I will probably look into either virtualization or a real arm machine where I can compile natively. Cross compiling for arm is just a pain.

That alone imposes such a big barrier that I am really wondering why the hell they don't (just_fix_it || stop_using_it_as_if_it_was_the_only_option). I guess large codebases are more often than not a problem._________________Gentoo Handbook | My website

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.

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

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

You're probably right. But the problem in this kind of build environments is that "the right pieces" are often undocumented. Or better said, they are documented but often not in portage anymore since docs about this are often ancient and outdated.

It's nothing specific to arm, I've had problems with mingw32 as well (and it was my own software not some pile of unfamiliar source code, so...).

I am probably incompetent when it comes to setting up cross-toolchains. But it's really hard to figure things out of thin air, and arm is a target that moves very quick these days, which doesn't help either. _________________Gentoo Handbook | My website