Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Building an arm/android toolchain
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures
View previous topic :: View next topic  
Author Message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Tue Jun 05, 2012 8:45 pm    Post subject: Building an arm/android toolchain Reply with quote

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


Last edited by i92guboj on Thu Jun 07, 2012 4:39 pm; edited 1 time in total
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Tue Jun 05, 2012 9:22 pm    Post subject: Reply with quote

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 :lol:

Code:
crossdev arm-unknown-linux-uclibceabi


That one worked.
Back to top
View user's profile Send private message
bixmix
n00b
n00b


Joined: 17 May 2012
Posts: 10

PostPosted: Wed Jun 06, 2012 6:49 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Wed Jun 06, 2012 3:41 pm    Post subject: Reply with quote

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 :wink:

Thank you for the info :)
Back to top
View user's profile Send private message
bixmix
n00b
n00b


Joined: 17 May 2012
Posts: 10

PostPosted: Thu Jun 07, 2012 4:02 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Thu Jun 07, 2012 7:28 am    Post subject: Reply with quote

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:

Code:
emerge-arm-gentoo-linux-gnueabi -va busybox


Compilation goes smooth, and a binary is produced. Problems start there, though:

Code:

$ ls -l /usr/arm-gentoo-linux-gnueabi/bin/busybox
-rwxr-xr-x 1 root root 868K jun  7 09:01 /usr/arm-gentoo-linux-gnueabi/bin/busybox
$ file /usr/arm-gentoo-linux-gnueabi/bin/busybox
/usr/arm-gentoo-linux-gnueabi/bin/busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
$ LC_ALL=C /usr/arm-gentoo-linux-gnueabi/usr/bin/ldd /usr/arm-gentoo-linux-gnueabi/bin/busybox
        not a dynamic executable


"file" and "ldd" seems not to agree, that, or my arm ldd is simply foobar'ed. Maybe I need to set some extra env?

Well, anyway...

The thing I am more concerned about is this:

Code:

$ readelf -d /usr/arm-gentoo-linux-gnueabi/bin/busybox

Dynamic section at offset 0xd7f08 contains 26 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]


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.

Any help is -nonetheless- welcome :lol:
Back to top
View user's profile Send private message
ssvb
Tux's lil' helper
Tux's lil' helper


Joined: 06 Nov 2003
Posts: 96

PostPosted: Thu Jun 07, 2012 7:41 am    Post subject: Reply with quote

Is your android phone using uclibc? 8O
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Thu Jun 07, 2012 7:57 am    Post subject: Reply with quote

ssvb wrote:
Is your android phone using uclibc? 8O


As said, my experience with uclibc starts now, I can't really tell.

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.

This is the header info for the libc.so file taken from my device.

Code:
$ readelf libc.so
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          52 (bytes into file)
  Start of section headers:          272980 (bytes into file)
  Flags:                             0x5000000, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         6
  Size of section headers:           40 (bytes)
  Number of section headers:         22
  Section header string table index: 21
Back to top
View user's profile Send private message
ssvb
Tux's lil' helper
Tux's lil' helper


Joined: 06 Nov 2003
Posts: 96

PostPosted: Thu Jun 07, 2012 8:02 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
bixmix
n00b
n00b


Joined: 17 May 2012
Posts: 10

PostPosted: Thu Jun 07, 2012 3:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Thu Jun 07, 2012 4:38 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Thu Jun 07, 2012 5:52 pm    Post subject: Reply with quote

bixmix wrote:
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. :lol:
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Fri Jun 08, 2012 6:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1646

PostPosted: Wed Aug 08, 2012 7:28 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Wed Aug 08, 2012 8:44 pm    Post subject: Reply with quote

No. But to tell the truth I didn't try hard. I was sucessful at building dynamic bins however, with a crossdev toolchain.
Back to top
View user's profile Send private message
lost+found
Guru
Guru


Joined: 15 Nov 2004
Posts: 509
Location: North~Sea~Coa~s~~t~~~

PostPosted: Tue Jul 16, 2013 6:29 am    Post subject: Reply with quote

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?

:?:
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Fri Jul 19, 2013 6:51 am    Post subject: Reply with quote

lost+found wrote:
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.
Back to top
View user's profile Send private message
lost+found
Guru
Guru


Joined: 15 Nov 2004
Posts: 509
Location: North~Sea~Coa~s~~t~~~

PostPosted: Fri Jul 19, 2013 4:02 pm    Post subject: Reply with quote

@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.
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Sat Jul 20, 2013 9:32 am    Post subject: Reply with quote

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.)
Back to top
View user's profile Send private message
i92guboj
Bodhisattva
Bodhisattva


Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)

PostPosted: Tue Jul 23, 2013 5:31 pm    Post subject: Reply with quote

cwr wrote:
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. :lol: :lol:
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on Alternative Architectures All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum