Related
This is the placeholder for the different toolchains used for compiling ARM targets (read - aosp, other projects/binaries)
I'll be updating this post tomorrow with download links.
First and most important will be the standard binutils/gcc combo.
Some time ago, I was really fed up with having to set up a 32bit chroot in order to compile aosp, which is why I decided to build my own native x86_64 toolchain.
Should you use it, you MUST have gmp and mpfr installed (libgmp, libmpfr).
I won't be bundling those for your distro.
I could make gmp-less and mpfr-less versions, but these enabled offer considerable a better code being built.
Packages:
[email protected]_4.4.4 - binutils 2.20.1, newlib 1.18.0, gcc 4.4.4
[email protected]_4.5.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.5.0
[email protected]_4.6.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.6.0 (I don't recommend using that one, since it's VERY experimental)
Notes:
If you want a stable, yet fast and bleeding edge system, use v4.4.4
You can use 4.5.0 to compile native apps, but compiling aosp with 4.5.0 fails on skia (you can always circumvent this by compiling skia first, changing to 4.4.4 and re-compiling aosp)
Once I get some time, I'll share uClibc toolchains/roots in order to get your busybox compile. ;]
>EDIT< linked 4.4.4 to download.
adwinp said:
This is the placeholder for the different toolchains used for compiling ARM targets (read - aosp, other projects/binaries)
I'll be updating this post tomorrow with download links.
First and most important will be the standard binutils/gcc combo.
Some time ago, I was really fed up with having to set up a 32bit chroot in order to compile aosp, which is why I decided to build my own native x86_64 toolchain.
Should you use it, you MUST have gmp and mpfr installed (libgmp, libmpfr).
I won't be bundling those for your distro.
Packages:
[email protected]_4.4.4 - binutils 2.20.1, newlib 1.18.0, gcc 4.4.4
[email protected]_4.5.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.5.0
[email protected]_4.6.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.6.0 (I don't recommend using that one, since it's VERY experimental)
Notes:
If you want a stable, yet fast and bleeding edge system, use v4.4.4
You can use 4.5.0 to compile native apps, but compiling aosp with 4.5.0 fails on skia (you can always circumvent this by compiling skia first, changing to 4.4.4 and re-compiling aosp)
Once I get some time, I'll share uClibc toolchains/roots in order to get your busybox compile. ;]
Click to expand...
Click to collapse
some questions ...
toolchain that you used to compile "hikari aosp?
can cause problems, compiling skia with 4.4.4 and then switch to 4.5.0 to compile the rest?
Regards,
robin04
robin04 said:
some questions ...
toolchain that you used to compile "hikari aosp?
can cause problems, compiling skia with 4.4.4 and then switch to 4.5.0 to compile the rest?
Regards,
robin04
Click to expand...
Click to collapse
4.4.4 is completely stable.
IF you want to play with 4.5.0, you'll have to compile with 4.4.4 first, strip all other binaries, then compile with 4.5.0.
I'll upload in the evening.
Hmm, I compiled the official Android sources without problem on my x64 box... used the supplied 4.4.0 toolchain in the ndk though, is that cheating? .
Are there any portability issues when you build a Hero rom? I mean, do you have to copy some binary libs here and there that won't work if the rest of the ROM is compiled with 4.5.0? You said something like that once I think.
Or is this a non-issue because we got complete source now that we have a 2.6.29 kernel? I thought we still use some binary HTC files somehow (never cooked an android rom before, just compiled AOSP once and left it there).
@dipje:
Yes, not all binaries are "cross-toolchain" compatible, with different reasons behind this. Wouldn't want to enumerate all of them, lol.
/me looks at his Linux boxes all being busy with compiles.... man there goes my electricity bill again .
You can probably guess the next question adwinp: are there any real benefits to using another gcc toolchain?
Did I see it correctly that you are building with the newlib C library instead of the bison C library? Any real (proven) benefits of choosing that one, or just your preference ?
-------------------------------------
Sent from my AOSP Hero Androbin
I've had some rare cases of breakage, but newlib is a stable base (for arm targets), proven to work.
Anyhow, it's only a middleware in order to get a proper gcc working (which is what's of interest to us, along with binutils).
I'll have to sort my uClibc in order to upload a proper release. Dunno if I'll have the time till tomorrow though, since on Friday, in the evening, I'm going to the UK for ~10 days.
Links are down..
Are you sure you need these toolchains, most kernels are buildable with the one you get from Android NDK you can download from google's site
For those of you who managed to install a linux distribution on android, is it possible to use aircrack?
I want to install linux on android for aicrack but the process is somewhat complicated so I would like to know if it's working at all?
How does I set up teh linux?
1- you dont know anything about linux. go ubuntu. we will tweak it after that. version 10.xxx (cant remember exactly).
2- you've used linux before and feel comfortable when thinking about it. go ubuntu/fedora.
3- no worries. you can troubleshoot alone when leenucks acts funny, you su everyday. go arch linux.
bottom line, it all comes to a few package versions.
make, python2, git, jdk, maybe a few others, need old versions. even in ubuntu, if you would like to start from a more updated base image, you'll need to downgrade. arch linux allows this with more freedom, since its more modular.
i havent used fedora for a few years now. used it back when red hat quit doing desktop images, didnt stay long and switched to slack.
i prefer archlinux because it's 300mb'ish iso, allows lvm, luks from live cd, doesnt have a text-based installer but install scripts, rolling release system (prebuilt packages/packages built from src using abs/aur, testing repo), customizable/modular, cli package manager (pacman ), systemd, grub2..
basically, if you like bleeding edge and power to yourself, try archlinux. read the wiki, begginer guide, install guide. first time i did it, i used another pc to help me go through all the steps.
sent from my i9250
When you're interested in Linux you can take a easy to use Distro like Ubuntu.
Packetmanagement resolves dependencies autocratically and nearly each software is available as a precompiled Packet
Also such Distros are running 32 and 64bit Programms out of the box.
If you want to learn linux in deep (and have enough time to solve issues) i recommend a Distro like Arch or Slackware.
I use Slackware64 and learned a lot about Linux and the packet and library dependencies.
Because the Packetmanagement does not resolve dependencies.
Even GUI Tools are rare on this Distro, you have to struggle with config files.
Slackware is a pure 32 or 64bit Linux (can be build to a Multilib Linux).
For Example the Android SDK mainly uses 32bit.
Maybe you should try some Distros and use that one you feel familiar with.
Also there are good Resources out in the net which you should read (Filesystem Hierarchy Standard, File Permissions, Basic Shell Tools)
Google and en.wikibooks.org/wiki/LPI_Linux_Certification would be a good starting point.
You could also try some Live-CDs, mess with it and when all went wrong only reboot.
Good Luck
Indeed, start Ubuntu, you can even stay with it if you like. But Arch and the install guide give you a good grasp on how Linux works.
Of course, you can develop apps in Windows or OSX, and OSX and Linux are the only two that allow you to build Android from source (basically ROM development). You also need to know Java to develop Android apps, less fun than screwing around with Ubuntu lol.
Good luck!
Sent from my Galaxy Nexus using xda app-developers app
Thanks for all the replies guys! Wish me luck lol.
RoyJ said:
Thanks for all the replies guys! Wish me luck lol.
Click to expand...
Click to collapse
Just to give one final thought, I think Slack would be a better learning experiencing, since it's even more close to Unix than Arch. With Arch you learn a lot, that's a fact, but with Slack you understand even how libraries and dependencies work, kinda the hard way, since you don't have a package manager to take care of it for you.
I think both might be a steep (maybe too steep) learning curve, and Ubuntu will be easier but, Ubuntu does things more their way. It's Linux, but things are different. Eventually, you'll know what i mean.
sent from my i9250
Thanks for the input. That's something to look into for sure. I am in no rush to just jump in and try it. I'd really like to learn everything on a basic level like that first.
I'm trying to get the research down before I start messing with the development.
Hey all. Ever since I learned about the ZF2 and it running on an Intel CPU/SoC vs a typical ARMv7 or ARMv9-based CPU/SoC this idea came to mind. Would it possible to develop a pure Linux (non-Android) based OS/ROM for this device? I run Funtoo Linux (a Gentoo derivative) on one of my desktops and now on a laptop I'm sharing with my brother, and it works great. Having this (or something Ubuntu-based to ease on pkg installs via binaries vs compiling from source for everything) on a phone this powerful would be awesome as well. Besides drivers for baseband / bootloader (of which I know is currently locked at the moment I'm posting this thread) how difficult would this be to accomplish? Does this device boot with EFI? I'd think compiling a kernel for it would be easier than a typical Android kernel since Intel spec is easier to compile for... I'm no developer, but that's my take on it.
Thoughts?
Hello everyone.
As in subject, I'm looking for a KVM Enabled Kernel, to flash on my device.
I'm looking for:
1) File to download
2) Commands to FastBoot
3) A way to ensure it works
Thanks in advance for any help.
Bye, Ivano.
P.S.: I forgot to mention, it's a ZE551ML Z00AD
P.P.S.: Nevermind, I successfully flashed KVM on device, but I can't use it on Limbo yet (I get an error about missing modules, but they're there).
Any help greatly appreciated.
I never got limbo to work, I have exact same model you have (Z00AD) and I've got kvm working with QEMU.. Limbo doesnt detect kvm properly it doesn't see the kernel modules loaded..
Theres a few guides on here how to use QEMU but as a VERY rough idea on what you need to do is:
Install a chroot linux on the phone (I used Linux Deploy to set up Ubuntu with Xterm)
After chroot setup, install qemu-kvm with apt. And on the Android OS install aSpice client from play store
Move the install images/hdd images to the phone storage (if preinstalled os hdd with Virtualbox or something)
Launch qemu with --enable-kvm and -cpu host to get kvm working, adjust other options as needed
Sorry for such a quick write up I'm busy atm, can help more later
My problem is that gpu won't work with chroot
You wont get gpu access with chroot, some devices have GPU's that have some support but unfortunately our
specific PowerVR chips dont have support.. using QEMU with kvm will allow you to still use all other parts of your hardware, and using spice will allow the use of the QXL video driver that provides some basic acceleration in the guest.
Either that or in the chroot compile and build your own version of qemu with -virglrenderer enabled, but the virgl option is very beta and may not work
Edit: Limbo is just a front end to QEMU so you wont have any new features that qemu doesn't have.. just Limbo is a port of qemu that's stripped down to work on Android
In this case, I don't need this anymore.
Thanks for your help.
What kind of 3D software/GPU needy task are you needing? Because in theory I've read that a linux chroot may still have some graphics acceleration on android devices due to some linux device firmware has OpenGL ES support (which is what runs on android devices, a subset of standard OpenGL) but how I personally am not sure.. I know there is GL4ES that supposed to allow OpenGL calls to be converted/linked to OpenGL ES calls but you would have to compile it from source as it's aimed at arm hardware..