Re: arm-linux-androideabi/arm-eabi/arm-unknow-linux-gnueabi

[gabx <arnaud dot gaboury at gmail dot com>]

On Tue, Jun 18, 2013 at 12:39 AM, Bryan Hundven-3 [via Sourceware.org] <
ml-node+s1504n235663h32@n7.nabble.com> wrote:

> Yann, Arnaud,
>
> On Mon, Jun 17, 2013 at 3:15 PM, Yann E. MORIN <[hidden email]<http://user/SendEmail.jtp?type=node&node=235663&i=0>>
> wrote:
>
> > Arnaud, All,
> >
> > On 2013-06-05 12:07 -0700, gabx spake thusly:
> >> I build Android ROM from AOSP for mobile device, LG google nexus 4
> >> (armv7-a).
> >> With android come several prebuilts/gcc/linux-86/arm toolchains named
> >> "arm-eabi-4.7" and "arm-linux-androideabi-4.7".
> >>
> >> I build my own toolchain which name is
> "arm-cortexa9_neon-linux-gnueabi"
> >> (cortex-a9) as CPU & TUNE and neon as FPU.
> >>
> >> I am a little confused about all these different names. The out folders
> from
> >> my built toolchaine are roughly similar to the androideabi prebuilt
> ones. Is
> >> the "gnueabi" and "androideabi" only a name specification (I understand
> >> android is not gnu) and a licence difference with same binaries/lib, or
> is
> >> there a real difference for the built outputs ?
> >> What about the arm-eabi ? Here again folders "look" quite similar to my
> >> toolchain, but why arm-eabi AND
> >> arm-linux-androideabi ?
> >
> > Those names are what is called a tuple.
> >
> > A tuple defines a complete system. It is split in three parts, separated
> > by hyphens (dashes):
> >
> >   - arch-vendor-abi
> >   - arch-vendor-os-abi
> >
> > For both tuple types:
> >   - arch, the hardware architecture: arm, armeb, armv6, i686, mips,
> >     powerpc, lapha...
> >   - vendor, identifies the vendor (or provider) of the toolchain, and is
> >     almost free form (but shall contain neither space nor dash,
> obviously),
> >     usualy something like: unknown, pc
> >
> > For the three-part tuples:
> >   - abi, defines the ABI of the system: elf, eabi...
> >
> > For the four-part tuples:
> >   - os, which defines the /kernel/ of the system. There are not many
> >     supoprted, the most common one being: linux
> >   - abi, the ABI of the system, the most comon being: gnu, gnueabi,
> >     uclibc, uclibcgnueabi, androideabi...
> >
> > The three-part tuples are mostly used for bare-metal, that is system
> > with no kernels at all (eg. bootloaders, or special applications running
> > directly on the CPU without a kernel).
> >
> > Currently, crosstool-NG does not support generating toolchains targeting
> > Android. With some trickery, you could turn a arm-unknown-linux-gnueabi,
> > or an arm-unknown-linux-uclibcgnueabi, or an arm-ubknown-eabi to
> > generate code for Android, but it's not really easy.
>
> In the end, the host tuple would be arm-linux-androideabi, but there
> are other toolchains in the android build system for different
> purposes:
>
> ---------- quote ----------
> The Android toolchain supports the following targets:
>
>    a. arm-linux-androideabi
>    b. arm-eabi  (for Android kernel)
>    c. arm-newlib-eabi (for runnng gcc regression tests)
>    d. i[3456]86-*-linux-gnu, x86_64-*-linux-gnu (for x86 targets)
> ---------- /quote ----------
> from: https://android.googlesource.com/toolchain/build/+/HEAD/README
>
> I think a better place to start for doing any work with the android
> toolchain, is by starting there with the toolchain/manifest repo:
>
> $ mkdir $HOME/android-toolchain
> $ cd $HOME/android-toolchain
> $ repo init -u https://android.googlesource.com/toolchain/manifest -b
> master
> $ repo sync -j<replace this with # of dl jobs>
>
> Same workflow as working with the android platform build.
>
> I think it would take more work then it's worth to build a toolchain
> for bionic with crosstool-ng, then it is to work with the existing
> tools provided by google.
>
> On the other hand, I have made cross toolchains with gcc, specifically
> for kernel builds, and arm-unknown-linux-gnueabi works fine for that
> (cortex-a8/armv7, in my experience), but at that point, you could just
> grab mentor's (67, not 68!) or linaro's arm gnueabi toolchains and
> they would work fine for that purpose as well.
>
> Anyways, I hope that is helpful info.
>
> -Bryan
>
> > Regards,
> > Yann E. MORIN.
> >
> > --
> >
> .-----------------.--------------------.------------------.--------------------.
>
> > |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> > | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
>       |
> > | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There
> is no  |
> > | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
> conspiracy.  |
> >
> '------------------------------^-------^------------------^--------------------'
>


Thank you all for your answer.

Yes, building bionic with a cross-toll made toolchain is a big pain. I
started to give it a try but it takes long as the build is full of errors.




--
View this message in context: http://sourceware-org.1504.n7.nabble.com/arm-linux-androideabi-arm-eabi-arm-unknow-linux-gnueabi-tp234300p236701.html
Sent from the Sourceware - crossgcc list mailing list archive at Nabble.com.

--
For unsubscribe information see http://sourceware.org/lists.html#faq