Related
Hi,
I've download the Android source with "repo", and it includes cross compiler toolchains for various architectures.
I want to build a package (for now, mtd-utils) for my android phone (a htc hero), but I'm having limited success understanding how to get this working. I was thinking there was something I could do, like change my $PATH and set up some other environment variables, that would use the tools from the toolchain instead of the system default ones, so that the binaries would be built for the phone instead of for my computer. But it certainly doesn't seem to be that easy...
I've reverted to attempting a "Hello world" program, but when I try to compile even that using the included toolchain tools, I run into trouble:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -o hello hello.c
hello.c:1:19: error: stdio.h: No such file or directory
hello.c: In function 'main':
hello.c:5: warning: incompatible implicit declaration of built-in function 'printf'
so I tried a couple of other variants:
Code:
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/bionic/libc/include -o hello hello.c
$ $HOME/src/mydroid/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-gcc -static -I $HOME/src/mydroid/ndk/build/platforms/android-8/arch-x86/usr/include/ -o hello hello.c
but they both give (different) errors about what other include files are missing when referenced from somewhere.
Is there some "easy" way to android-ify a source tree, so that I can build sources using the cross compiler toolchains? Or should I fetch a different cross compiler toolchain to use, like benno did in his document from 2007? He uses a codesourcery toolchain and builds with that instead (as referenced in other articles here on the subject).
Would much appreciate any shared tips or experiences on how to accomplish this.
The tool chain is fine the problem is non of the include/lib are set up correctly to find the needed version of the includes. Remember the default includes under linux depend on glibc and android only supplies bionic.
Have a look here for more info on setting up bionic:
http://android-dls.com/wiki/index.php?title=Compiling_for_Android
Though if you get the full source for glibc (or precompiled arm binaries) you could compile a dependant program staticly (I think that's what busybox does)
Building for older versions of Android
I was actually able to compile a program manually today, specifically one of the programs in the mtd-utils package. After lots of jumping back and forth, I have found out that the 64 bit version of Ubuntu is what I needed, and also sun-java-1.6, contrary to almost all information I found out there. Then I was able to build AOSP, and then I was able to get "agcc" working, the wrapper that sets environment variables automatically as needed.
So I compiled the app, but it didn't work on my Android. Trying to run it in an adb shell gave approximately this error (from memory):
/bin/sh: ./program: No such file or directory
though the program was there. I didn't use strace, but concluded that this is because of a missing shared library. I have a very recent version of AOSP, while the phone is running Android 2.0 or something like that, so that's a plausable reason why this is happening.
I tried to rebuild the program using "agcc -static ...", but that doesn't work because I don't have the static version of libc after building AOSP, so it just dies with a linker error complaining that it can't find -lc.
So now I need to figure out how to build for old Android version using my checked out version of AOSP, or I need to figure out how to check out an old version of AOSP using repo.
Any tips would be much appreciated.
After much frustration with getting things to work on Ubuntu, I switched back to Kali Linux and attempted the same procedure described here ... http://wiki.cyanogenmod.org/w/Build_for_d2spr ... as well as for Ubuntu here ...http://source.android.com/source/initializing.html .... When a step for Ubuntu 10 didn't work I tried the Ubuntu 11 or 12 approach and something always went through regarding setting up the build environment.
***Update-3: Sat Nov 9, 9:59 AM 2013 (Building CM_10.2 : Android_4.3 in progress as of 10:33 AM)***
Well I screwed up my Linux installation last night trying to put my /usr dir on a seperate partition and some file permission issues broke out with sudo, though everyone suggest 04755, thats what it was at. Kinda trippy, anyways so I found myself having to go through these steps again which gave me a chance to update this:good:...
***These are the packages I installed***
Code:
sudo apt-get install git git-core gnupg flex bison gperf \
build-essential zip curl lib32ncurses5-dev libc6-dev libgl1-mesa-dev \
lib32readline-gplv2-dev g++-multilib gcc-multilib mingw32 tofrodos \
python-markdown lib32z1-dev libxml2-utils xsltproc \
libesd0-dev libsdl1.2-dev libwxgtk2.8-dev lzop \
pngcrush schedtool squashfs-tools
The next thing you need to do after getting the build packages to install^^^ is install sun-java6-jdk which you can do following the "kind-of" instructions below regarding debian packages, unixodbc es la pinche problema, (If you see anything I am missing please please inform me).
or
You can install the *.bin file/s from Oracle here http://www.oracle.com/technetwork/j...ds/java-archive-downloads-javase6-419409.html and follow their instructions for getting it installed.
***Notes on sun-java6-jdk debian packages***I just finished installig sun-java6-jdk and it's dependencies, I downloaded the packages from here ... http://packages.debian.org/squeeze/sun-java6-bin ... all packages were installed using 'sudo dpkg -i [./the/package/was/a.deb]' . For 'unixodbc' I used the dpkg but got an error and ended up using 'sudo apt-get install unixodbc', but that gave a warning about breaking and needing to remove other packages, I did not do that. Then 'sudo apt-get -f install' because it asked me to unless there was another solution. Becarefull and you should be fine. Due to not installing the packages in a specific order I had a run around of a time doing this but it was not too bad, plan ahead and it will be easier. [Note- Makes sure you get all the packages, ie the *-common, *-bin, *-jre, *-jdk etc, etc ]
***Update-3:Continued***Once you have your new jdk installed don't forget to update alternatives, the alternative manager is basically a really useful tool for keeping track of links in your $PATH to different program versions, for instance if you have two versions of Java, then one will be linked to /usr/bin/java and that link points to the executable with a particular version usually maintained by the "alternatives" program. When you update this 'alternative' java version what you are doing is changing the link /usr/bin/java to point to the executable installed by the sun-java6-jdk package instead of the open-java6-jdk executable. I also like to repoint Eclipse to use sun-java6-jdk as well just to keep it all the same. You can update Eclipse's JDK location from within Eclipse, but I won't go into that here. If you installed java6 with the debian packages as I did, then your sun-java6-jdk installation should be located in "/usr/lib/jvm/java-6-sun-1.6.0.26". If its not there, try issuing this command...
Code:
dpkg -L sun-java6-jdk
...the output may be long, but it will tell you where everything got installed to, you can replace the package name with any other package whenever you need to know where all of it's files get installed, very useful.
Updating alternatives should look something like this depending on which version of the JDK you installed
Code:
sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/java-6-sun-1.6.0.26/bin/java"
, so Google "how to update alternatives for java" or something like that, I might be forgeting something, I have just been trying **** out till it works. You can varify that indeed you are using the correct java executable by issuing the following command...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR]
p.s. If thats not the correct output, please let me know.
While your checking version numbers, go ahead and check Git, Python, and Make.
from http://source.android.com/source/initializing.html
Python 2.6 -- 2.7, which you can download from python.org.
GNU Make 3.81 -- 3.82, which you can download from gnu.org,
JDK 6 if you wish to build Gingerbread or newer; JDK 5 for Froyo or older. You can download both from java.sun.com.
Git 1.7 or newer. You can find it at git-scm.com.
Click to expand...
Click to collapse
Checking the versions should look something like this...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$ [/COLOR]python --version
Python 2.7.3
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for x86_64-pc-linux-gnu
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] git --version
git version 1.7.10.4
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR]
***Notes on Android SDK*** The Android SDK should already be installed on Kali Linux or at least is when I install using a mirror to get extra packages. All you have to do is this, (I never build as root so you should create another user before doing building.):
Code:
echo "" >> ~/.bashrc
echo "#OURCHANGES" >> ~/.bashrc
echo "export ANDROID_SDK=\"/usr/share/android-sdk\"" >> ~/.bashrc
echo "export PATH=\"\${PATH}:\${ANDROID_SDK}:\${ANDROID_SDK}/tools:\${ANDROID_SDK}/platform-tools\"" >> ~/.bashrc
and then "cat ~/.bashrc" to make sure the changes went as planed.
Code:
cat ~/.bashrc
then "source ~/.bashrc"
Code:
source ~/.bashrc
then "android" and the gui should pop up and you can install all the lates updates or older ones if you want.
Code:
android
Then execute "which adb" it should result in this output "/usr/share/android-sdk/platform-tools/adb"
Code:
which adb
***Notes on USB and ADB***
Also, don't forget the USB rules for your device. I just used the sytax from source.android.com/source/initializing.html but make sure to add your username that you build with to the OWNER=<"some-user-name-here-is-important"> and I usually change 600 to 666. Also, you don't need all the enteries, just the ones for the device you have you can find the idVendor and idProduct by using the command "lsusb" with your device plugged in, it will look like this.
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~$[/COLOR] lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 007: ID [COLOR="Red"]04e8:6860[/COLOR] Samsung Electronics Co., Ltd GT-I9100 Phone [Galaxy S II], GT-P7500 [Galaxy Tab 10.1]
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 0489:e04e Foxconn / Hon Hai
Bus 002 Device 003: ID 1bcf:2c17 Sunplus Innovation Technology Inc.
What is in red above ^^^ are the {idVendor}:{idProduct}. I am not sure what to do with fastboot, I am still also learning.
The following is exactly as I have it in my "/etc/udev/rules.d/51-android.rules" file...
Code:
[COLOR="Red"][email protected][/COLOR][COLOR="Navy"]:~/cyandekali/system$[/COLOR] sudo cat /etc/udev/rules.d/51-android.rules
[sudo] password for edge-case:
# adb protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="[COLOR="Red"]04e8[/COLOR]", ATTR{idProduct}=="[COLOR="Red"]6860[/COLOR]", MODE="0666", OWNER="<edge-case>"
# fastboot protocol on maguro/toro (Galaxy Nexus)
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="4e30", MODE="0666", OWNER="<edge-case>"
Once you have your build enviroment set up you can build CyanogenMod for your device by initializing repo to your chosen repository and then sync'ing it up, most ROMs have their own little tweaks and optimizations so the guide can branch off into many directions at this point. (as far as I know it should work with most if not any other ROM, it worked with ReVolt). If you have any questions what so ever just ask, we all starte somewhere, and vise versa, if I need to be corrected anywhere please take the minute to post a reply, everyone will benifit from it.
And after a long day:
Code:
Package Complete: /home/edge-case/cyandekali/system/out/target/product/d2spr/cm-10.2-20131109-UNOFFICIAL-d2spr.zip
***The rest is history***Eventually I am going to modify this all so that Android and Kali will become one, I really really want to test my nfs server with my phone as a client
Edit/Update 1: I installed the .zip I built on Kali and it got stuck during boot or init, right before the spinning circle usually comes up. I will try again with sun-java6-jdk and libgeofence.so and report back.
Edit/Update 2: I initialized 'brunch d2spr' without the 'libgeofence.so', I have no idea how vital it is, I am assuming it is only needed for gps. If this fails to boot, then I will add the blob manually and test again.
A question I do have though. Should I be worried about "warning"'s? They come up every now and again it seems like they are C variables or something that get set to UCHAR or unsigned char and warnnings like that, are there any caveats I need to look out for?
The following is what I am refering to, how worried should I be about stuff like this, this build is missing libgeofence.so as stated.
Code:
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp: In member function 'void WebCore::SQLiteDatabase::setSynchronous(WebCore::SQLiteDatabase::SynchronousPragma)':
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'long unsigned int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'long int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: passing 'WebCore::SQLiteDatabase::SynchronousPragma' chooses 'int' over 'unsigned int' [-Wsign-promo]
external/webkit/Source/WebCore/platform/sql/SQLiteDatabase.cpp:229:75: warning: in call to 'static WTF::String WTF::String::number(int)' [-Wsign-promo]
In hindsight, the above ^^^ just meant it was working, just in case your wondering the same thing, if you see that kind of output after starting your build, you probably can go make some dinner or take a nap espescially if it's the first build, then you might want to go out to the movies or something, unless your like me and like trying to read stdout as it flys up the screen :good::good::cyclops:
I used Open-Java6-JDK and at the initialization of the 'brunch d2spr' command it complained about the Java Version but continued to build, I haven't installed the zip as I also on a rush built without 'libgeofence.so' or some such 'glob'.
Also, I am having trouble finding an official source to download 'libgeofence.so' , does anyone have a link they can point me to?
I did get this one but I have no idea about it's trust worthyness....http://downloads.codefi.re/houstonn/lgog_pro/unzipped/lib/libgeofence.so
Actually CM 10.2 but I need 10.1 [Reason 4 Failure?]
Ok so I built the second zip using sun-java6-jdk with no libgeofence.so, it installed but did not boot properly as did the first try with open-java6-jdk.
I did a 'make clean' and this was the output :
Code:
[COLOR="Red"]PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=[B][COLOR="Blue"]4.3.1[/COLOR][/B]
CM_VERSION=[B][COLOR="Blue"]10.2[/COLOR][/B]-20131013-UNOFFICIAL-d2spr
TARGET_PRODUCT=cm_d2spr
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=krait
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.7-trunk-amd64-x86_64-with-debian-1.0
HOST_BUILD_TYPE=release
BUILD_ID=JLS36I
OUT_DIR=/home/edge-case/CyAnDeKaLi/system/out
[/COLOR]
It may vary well be that it is trying to build for Android 4.3.x , what do you think?
I am thinking it was from the 'repo sync -j4 -c', what can I execute to clean my repo and re-sync it with 4.2.1 or 4.2.2 ?
Which I guess would be CM 10.1.x instead of CM 10.2.x (which may not be compatible with my phone's firmware)
Edit/Update: As I was looking through the nightlies at the CM website I noticed a "fix boot hang" version of CM 10.2 this may be a known issue with 10.2, also I guess the command is during the repo init:
Code:
[COLOR="Indigo"]repo init -u git://github.com/CyanogenMod/android.git -b [COLOR="Red"][B]cm-10.2[/B][/COLOR][/COLOR]
I guess I will just delete everything and start fresh replacing 10.2 with 10.1 and see how things go. Maybe the build was more "successful" than I thought after it didn't boot (ie the build went fine but the code just isn't there yet), or missing that libgeofence.so is fatal.
I had an idea that kinda relates to the topic, what if people where able to donate their C-CACHE's to the "cloud" so that other developers could speed up theirs, like a kind of high availability cluster. Though some kind of algorithm would need to be developed to identify whats what and what different and more than I can think of right now.
It really did work!
It is confirmed, the build is working on Kali Linux, I suppose I could write a step by step guide if any body asks.
Now the next step...Sewing CyanogenMod Android Debian Kali Linux into CyAnDeKaLi.
Sent from Samsung Galaxy SIII SPH-L10 running CyanogenMod 10.1 built on Kali Linux.
Cleaned it up a bit, more of a guide, this would probably work on most Debian distros.
If the Orange is too much, let me know but for now it is all the new stuff in case you were following along, most of the other stuff is just me talking to myself in public.
peace,
Edge-Case
I successfully built CM 10.2 on Kali Linux by following CyanogenMod's instructions on their wiki.
I thought I was the only one who was building ROM on Kali linux, But I was wrong
KALI LINUX FTW!!
mzahmed95 said:
I successfully built CM 10.2 on Kali Linux by following CyanogenMod's instructions on their wiki.
I thought I was the only one who was building ROM on Kali linux, But I was wrong
KALI LINUX FTW!!
Click to expand...
Click to collapse
Run Kali with Cyanogenmod (no chroot)?
Edge-Case said:
Run Kali with Cyanogenmod (no chroot)?
Click to expand...
Click to collapse
Sorry, But I didn't get your question....
Sent from my GT-N7100 using Tapatalk
mzahmed95 said:
Sorry, But I didn't get your question....
Sent from my GT-N7100 using Tapatalk
Click to expand...
Click to collapse
Ah, just a lil' project I decided to torture myself with. It's CyanogenMod with added Linux executables I picked from Kali's and Debian's armhf repos. It requires glibc to be placed in /lib of the Android file system hierarchy, which is normally not there. Also, a few tweaks to file and directory permissions need to be done, with out those tweaks to Android before the build, /lib and everything in it won't be executable and the owner:group gets changed to something like root:shell 644 or something. It has to do with the sticky bit that I am still trying to fully comprehend as Android implements it as a security feature. I heard removing a configuration flag to the kernel when building will get rid of the whole paranoid feature and allow more access to thing like file/socket creation.
Basically, Android with apt, nmap, wireshark-cli, aircranck-ng, tcpdump(which comes from the Android ports), and what ever else anyone wants really, even the whole (what works on arm that is) Kali pentesting suite if desired.
Though one caveat is that both glibc and bionic have to be loaded up into memory (RAM) from what I understand, and the amount of that resource varies, as well as /system storage (which is about 2g on sph-l710), but bind mounting from .img file or extSdCard also works (so long as owner:group and sticky bit has been adjusted correctly before build). Though I am having trouble mounting during init, so I just run a script when I turn my phone on, about to auto script it as a service or just use sl4a's feature. I got one builld that is a bit of a skeloton working, but all my attempts to tweak init.rc to mount what I want have resulted in failure to boot.
I am almosted tempted to take a BSD rootfs and try to hack together something that will boot BSD with Android as the "window server" taking the place of kde4 or gnome2. It would be an endever, maybe I should stick with debian based linux because it alsready runs on Android so long as glibc is available.
Edit: Interestingly enough I found this in FreeBSD's "/usr/ports/devel/android-tools-adb"
Code:
[email protected]:/usr/ports/devel/android-tools-adb$ cat pkg-descr
Android Debug Bridge (adb) is a versatile command line tool that
lets you communicate with an emulator instance or connected
Android-powered device.
WWW: http://developer.android.com/tools/help/adb.html
[email protected]:/usr/ports/devel/android-tools-adb$
I just got done building openjdk6, I saw bison, gcc, I have git, python27.... hmm....I heard about a Linux compatability layer... It might be more possible than I thought to build on FreeBSD. I searched "Build Android on FreeBSD" and saw some projects such as BroidSD, BSDroid (which looks like its bit rotting), GnatDroid. I think BSDroid even wanted to get Android running on the FreeBSD kernel!
I think watchdog needs to be picked out of NetBSD's arm rootfs though.
edit 2: Taada
Code:
[email protected]:/usr/ports/devel/android-tools-adb #make install
.....
.....
.....
===> Installing for android-tools-adb-4.3
===> Generating temporary packing list
===> Checking if devel/android-tools-adb already installed
install -s -o root -g wheel -m 555 adb /usr/local/bin/
===> Registering installation for android-tools-adb-4.3
===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/bin/adb
If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type 'make deinstall'
to deinstall the port if this is a concern.
For more information, and contact details about the security
status of this software, see the following webpage:
http://developer.android.com/tools/help/adb.html
[email protected]:/usr/ports/devel/android-tools-adb #
Not quite a build environment on FreeBSD yet, but hey, adb is a good start. As long as the dependencies are there it should work. I might need to set some enviroment variables if I do try to build on FreeBSD.
Code:
[email protected]:/etc/devd # adb devices
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
List of devices attached
c90855ae device
[email protected]:/etc/devd #
Just make sure to accept the rsa key on the phone/tablet... I almost thought I had more configuration to do but no, it works.
Update: Fri Nov 22, 2013
Well of all the build-tools I have these installed on FreeBSD:
bison, curl, flex, git, gperf, gnugp, open-jdk-6, open-jre-6, pngcrush, squashfs-tools, xsltproc, and zip.
These I don't have or don't know if I do have and they are named differently:
build-essential, lzop, schedtools, zlib1g-dev, libesd0-dev, libncurses5-dev, libsdl1.2-dev, libwxgtk2.8-dev, libxmil2-utils, g++-multilib, gcc-multilib, lib32ncurses5-dev, lib32readline-gplv2-dev, and lib32z1-dev.
If anyone has any knowledge they'd like to share regarding the packages I can't find and their possible counterparts for FreeBSD, please do share.
Note: It may be easier to build within a debian chroot/jail. -> ( http://blog.vx.sk/archives/22-Updated-Tutorial-Debian-GNUkFreeBSD-in-a-FreeBSD-jail.html )
BSDeb Chroot notes:
- I couldn't access the internet to apt-get at first in the jail, so I exited and then chrooted back into it and networking worked.
- squeeze's dpkg is old, upgrade to wheezy to get multi-arch support. -> ( http://www.howtoforge.com/how-to-upgrade-debian-squeeze-to-wheezy )
- I ran into this error while upgrading:
Code:
[....] Mounting kernel filesystems...mount: fdescfs : No such file or directory
invoke-rc.d: initscript freebsd-utils, action "start" failed.
dpkg: error processing freebsd-utils (--configure):
subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
Errors were encountered while processing:
freebsd-utils
E: Sub-process /usr/bin/dpkg returned an error code (1)
This fixed that:
Code:
mount -t fdescfs fdescfs /jail/debian/dev/fd/
Update on FreeBSD Debian chroot:
I couldn't install some packages, with squeeze because dpkg doesn't support multiarch at version 1.5. After upgrading to Wheezy, libc6-dev or libc6-dev:i386 could not be installed, was using libc0.1 for KFreeBSD Debian. Also lib32ncurses5-dev and lib32readline-gplv2-dev could not be installed with Wheezy. Perhaps with Jesse or Sid.
Oh well, enough of that, time to study.
[SIZE="+1"]What is a Cross-Compiler?[/SIZE]
A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. Cross compiler tools are used to generate executables for embedded system or multiple platforms. It is used to compile for a platform upon which it is not feasible to do the compiling, like microcontrollers that don't support an operating system. From wikipedia
Click to expand...
Click to collapse
[SIZE="+1"]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE="+1"]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE="+1"]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE="+1"]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE="+1"]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
[email protected]:~# apt-get update && apt-get install checkinstall
Click to expand...
Click to collapse
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
The NDK is a toolset that allows you to implement parts of your app using native-code languages such as C and C++.
Click to expand...
Click to collapse
[email protected]:~# wget http://dl.google.com/android/ndk/android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# tar xvf android-ndk-r9d-linux-x86_64.tar.bz2
[email protected]:~# mv android-ndk-r9d ndk
Click to expand...
Click to collapse
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
[email protected]:~# cd ndk/
[email protected]:~/ndk# build/tools/make-standalone-toolchain.sh --toolchain=arm-linux-androideabi-4.8 --platform=android-18 --install-dir=/root/ndkTC
Copying prebuilt binaries...
Copying sysroot headers and libraries...
Copying libstdc++ headers and libraries...
Copying files to: /root/ndkTC
Cleaning up...
Done.
Click to expand...
Click to collapse
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
[email protected]:~# wget https://dl.dropboxusercontent.com/u/23869279/Files/cc.sh
[email protected]:~# chmod 755 cc.sh
Click to expand...
Click to collapse
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
Click to expand...
Click to collapse
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
[email protected]:~# source cc.sh
Done setting your environment
CFLAGS: -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__
LDFLAGS: -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
CC points to arm-linux-androideabi-gcc and this points to /root/ndkTC/bin/arm-linux-androideabi-gcc
Use "$CC" command for calling gcc and "$CCC" command for calling our optimized CC
Use "$CXX" command for calling g++ and "$CCXX" for calling our optimized CXX
Use "$STRIP" command for calling strip and "$SSTRIP" command for calling our optimized STRIP
Example: "$CCC myprogram.c -o mybinary && $SSTRIP mybinary "
When using makefiles with configure options, always use "./configure $CONFIGANDROID" instead of using "./configure" itself
Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself
Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else
Click to expand...
Click to collapse
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[email protected]:~# echo $CC
arm-linux-androideabi-gcc
[email protected]:~# echo $CCC
arm-linux-androideabi-gcc -O2 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp -s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing -DNDEBUG -D__ANDROID__ -Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections
Click to expand...
Click to collapse
[SIZE="+1"]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
[email protected]:~# $CCC hello.c -o hello && $SSTRIP hello
Click to expand...
Click to collapse
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
[email protected]:~# readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "ARM v7"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3
Tag_Advanced_SIMD_arch: NEONv1
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
[email protected]:~# readelf -A hello2
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "5TE"
Tag_CPU_arch: v5TE
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_optimization_goals: Aggressive Speed
Tag_DIV_use: Not allowed
Click to expand...
Click to collapse
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE="+1"]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
[email protected]:~/shared# adb shell
[email protected]:/ # sysrw
[email protected]:/ # exit
[email protected]:~/shared# adb push hello /system/bin/hello
95 KB/s (5124 bytes in 0.052s)
[email protected]:~/shared# adb shell
[email protected]:/ # chmod 755 /system/bin/hello
[email protected]:/ # chown root:system /system/bin/hello
[email protected]:/ # exit
Click to expand...
Click to collapse
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE="+1"]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
JustArchi said:
[SIZE=+1]What is a Cross-Compiler?[/SIZE]
[SIZE=+1]How is that connected with an Android?[/SIZE]
In order to create a native C/C++ binary for an Android, you must firstly compile the source code. Usually you can't do so on an Android itself due to lack of proper tools and environment, or hardware barriers, especially amount of RAM. This is why you should learn how to cross-compile, to create a binary on your PC, that your ARM-based Android will understand.
[SIZE=+1]Why do I need it?[/SIZE]
You need to learn cross-compiling technique if you want to run native C/C++ programs on an Android. Actually, if you've already built your own custom ROM from AOSP sources (i.e. CyanogenMod), then you used cross-compiling tools and methods even without noticing .
Building an AOSP ROM is fairly easy, there's one command like brunch, which does the job. However, what if you want to compile a custom, not natively included binary? This is the purpose of this tutorial.
[SIZE=+1]What I will learn from this guide?[/SIZE]
How to properly set C/C++ building environment
How to build a native C/C++ application for Android device
How to optimize native binaries for my device
[SIZE=+1]Step 1 - The Beginning[/SIZE]
You should start from installing any Linux-based OS, I highly suggest trying a Debian-based distro (such as Ubuntu), or even Debian itself, as this tutorial is based on it .
In general, I highly suggest to compile an AOSP ROM (such as CyanogenMod) for your device firstly. This will help you to get familiar with cross-compiling on Android. I also suggest to compile one or two programs from source for your Linux, but if you're brave enough to learn cross-compiling without doing any of these, you can skip those suggestions .
[SIZE=+1]Step 2 - Setting up[/SIZE]
Firstly you should make sure that you have all required compile tools already.
This should do the trick and install all required components.
I suggest creating a new folder and navigating to it, just to avoid a mess, but you can organize everything as you wish.
Start from downloading NDK from here.
Now you should make a standalone toolchain, navigate to root of your ndk (this is important) and then build your toolchain:
You should edit bolded variables to your preferences. Toolchain is the version of GCC you want to use, 4.8 is currently the newest one, in the future it may be 4.9 and so on. Platform is a target API for your programs, this is important only for android-specific commands, such as logging to logcat. When compiling a native Linux program, this won't matter (but it's a good idea to set it properly, just in case). Install dir specifies destination of your toolchain, make sure that it's other than ndk (as you can see I have ndk in /root/ndk and toolchain in /root/ndkTC).
Now you need to download my exclusive cc.sh script from here and make it executable.
This script is a very handy tool written by me to make your life easier while cross-compiling. Before running it make sure to edit "BASIC" options, especially NDK paths. Apart from that it's a good idea to take a look at DEVICEFLAGS and setting them properly for your device, or clearing for generic build. You don't need to touch other ones unless you want/need them.
Just for a reference, I'll include currently editable options:
As you can notice, my magic script already contains bunch of optimizations, especially device-based optimizations, which are the most important. Now it's the time to run our script, but in current shell and not a new one.
Command "source cc.sh" executes cc.sh and "shares" the environment, which means that any exports will be exported to our current shell, and this is what we want. It acts the same as AOSP's ". build/envsetup.sh", so you can also use . instead of source.
As you can see above, my script should let you know if it properly set everything, especially if $CC points to our ndkTC. It also set a generic "$CCC" and "$CCXX" commands, which are optimized versions of standard $CC. $CC points to our cross-compiler, $CCC points to our cross-compiler and also includes our optimization flags.
[SIZE=+1]Step 3 - Cross-Compiling[/SIZE]
Now we'll compile our first program for Android!
Create a new file hello.c, and put inside:
Code:
#include <stdio.h>
int main (void)
{
puts ("Hello World!");
return 0;
}
Now you compile and strip it:
Remember that $CCC and $SSTRIP command will only work if you source'd cc.sh script explained above. $CCC command compiles source code to a binary with already optimized flags (device flags, optimization level, optimization flags, linker flags), while $SSTRIP command strips "bloat" from output binary, such as comments and notices. The purpose is to make a binary smaller and faster.
You can check if your binary has been compiled properly through readelf command.
As you can see, I've compiled a binary optimized for ARM v7, with THUMB-2 instructions and NEON support. How nice! Is it because of device-specific flags? Let's check what happens if we use $CC instead of $CCC:
As you can see, if you do not specify flags, you'll lose major portion of optimizations. Of course binary will work properly, hence it has been cross-compiled for ARM, but we can always make it smaller and faster!
[SIZE=+1]Step 4 - Testing[/SIZE]
A favourite part of everything, tests!
In above example I pushed my binary straight to /system/bin directory, which is in the Android's PATH. If you don't have rooted device that's not a problem, you can use /data/local directory or /storage/sdcard0. You can also upload your binary anywhere you want and download it as any other file, then run from /storage/sdcard0/Download, this way doesn't require even working ADB . Just don't forget about setting proper permissions afterwards!
Now let's try to run it!
If your binary is not in the PATH, you should write full path to your binary of course. As I pushed my binary to /system/bin, I don't need to do so.
If everything finished successfully and you got your very first Hello World response as above, congratulations. You've just compiled and ran your first native C/C++ program on Android device.
[SIZE=+1]What to do next?[/SIZE]
In theory, you can now compile anything you want. Here are some apps that I'm using in my ArchiDroid ROM:
Pixelserv
Haveged
Dnsmasq
DNRD
Rinetd
These are only a few examples. You can compile anything you want, or even write your own native applications. Good luck!
Click to expand...
Click to collapse
[Mod Edit: Please don't quote the whole OP]
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
dicksteele said:
Fricking awesome. Worked perfect on my builduntu running in VirtualBox
Click to expand...
Click to collapse
I'm very glad it worked for you .
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Dragoon Aethis said:
Maybe you happen to know which packages checkinstall depends on? I want to run this on Arch - pun not intended - and pacman doesn't exactly talk with debs.
(Przy okazji, świetny tutorial c: )
Click to expand...
Click to collapse
Checkinstall makes sure that you have all required packages installed. You can achieve nearly the same by installing "build-essential, gcc, g++, make", and that should be enough I guess .
Also, big kudos to @willverduzco for featuring my guide on XDA portal!
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
DerRomtester said:
I would like to see a guide for llvm/ clang.
Sent from my GT-I9000 using xda app-developers app
Click to expand...
Click to collapse
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
EnerJon said:
maybe a bit irrelevant... but i wanted to learn how to cross compile/port a binary (for example "applypatch") for cygwin... any link to guide will be helpful
Thank You
Click to expand...
Click to collapse
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
JustArchi said:
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
EnerJon said:
Actually i was making a tool for windows to generate/apply OTA for Android ROMs... i wanted to compile/port "IMGDIFF2" and "applypatch" from android sources...
Click to expand...
Click to collapse
Then you should find your sources for IMGDIFF2 and applypatch and compile from source for Android, just like example hello.c above.
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
JustArchi said:
When making standalone toolchain you should use clang instead of gcc. You should also study my cc.sh script and adapt to your own. After that, steps are nearly the same.
Using Cygwin for such kind of things is... bad. Install VirtualBox and any Linux distro if you want to master cross-compile technique.
Click to expand...
Click to collapse
I try this. I would like to cross compile a kernel with clang. Hopefully i get it working.
Odysseus1962 said:
@JustArchi I saw this guide mentioned on the portal and read through it. Very interesting stuff. Great work explaining. I've got several questions, however, perhaps you can elaborate on.
My primary PC OS is Gentoo Linux (I've been using it for 10 years), in patricular ~amd64 which is the equivalent of Debian unstable. In Gentoo, all packages are compiled from the sources. I have a very up to date complete toolchain already installed and functioning properly as part of the native package installation system which uses portage for maintaining and updating.
I've already compiled CM and AOSP for my device, but I can't for the life of me understand why when setting up my build environment using either Google or CM tools several much older versions of GCC and GLIBC are installed into my source repos and used to build the ROM when the prerequisites for building the environment already require a working toolchain on the host build box?
Isn't there a way to just use the native toolchain from the host? Ideally, I'd love to free up the space used by these extra compilers and libraries for sources instead. Additionally, since my toolchain is much newer (gcc-4.8.2, glibc-2.19, etc) and optimized for my hardware than these generic prebuilt binaries, my ROM builds would compile faster and more optimized if I could use it instead.
The big question I ask is would you know what I'd have to do to setup my native environment to build Android? I'd truly love to be able to get rid of these other toolchains and free up the space on my harddrive. Any help would be greatly appreciated. TIA
Click to expand...
Click to collapse
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
JustArchi said:
You need special compiler capable of compiling for specific architecture, this is not the same as native GCC toolchain for amd64. When you're using native compiler, output is always designed for amd64 or i386, when using cross-compiler, output is always designed for ARM, or other specific architecture.
Click to expand...
Click to collapse
Thanks for the quick response. I'm a bit disappointed, but I'm still wondering that there has to be some way for me to utilize the ARM toolchain I currently have installed to cross-compile from the sources a more updated optimized toolchain for me to build with. Unfortunately (for me), that Gentoo is more of a niche Linux distro so finding help in their forums for working with ARM is difficult. As it is, it took much effort and trial and error to setup my current configuration to build with since nearly everything on the net is geared towards Ubuntu / Debian (both of which I feel are loaded with useless cruft and dependencies for things I have never and will never use).
Anyhow thanks again for this great guide, and for your continued work here helping us all.
Ciao
Dropbox link is down
Inviato dal mio GT-I9300 utilizzando Tapatalk
Code:
#!/bin/bash
# _ _ _ _ _
# | |_ _ ___| |_ / \ _ __ ___| |__ (_)
# _ | | | | / __| __| / _ \ | '__/ __| '_ \| |
# | |_| | |_| \__ \ |_ / ___ \| | | (__| | | | |
# \___/ \__,_|___/\__/_/ \_\_| \___|_| |_|_|
#
# Copyright 2014 Łukasz "JustArchi" Domeradzki
# Contact: [email protected]
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#############
### BASIC ###
#############
# Root of NDK, the one which contains $NDK/ndk-build binary
NDK="/root/ndk"
# Root of NDK toolchain, the one used in --install-dir from $NDK/build/tools/make-standalone-toolchain.sh. Make sure it contains $NDKTC/bin directory with $CROSS_COMPILE binaries
NDKTC="/root/ndkTC"
# Optional, may help NDK in some cases, should be equal to GCC version of the toolchain specified above
export NDK_TOOLCHAIN_VERSION=4.8
# This flag turns on ADVANCED section below, you should use "0" if you want easy compiling for generic targets, or "1" if you want to get best optimized results for specific targets
# In general it's strongly suggested to leave it turned on, but if you're using makefiles, which already specify optimization level and everything else, then of course you may want to turn it off
ADVANCED="1"
################
### ADVANCED ###
################
# Device CFLAGS, these should be taken from TARGET_GLOBAL_CFLAGS property of BoardCommonConfig.mk of your device, eventually leave them empty for generic non-device-optimized build
# Please notice that -march flag comes from TARGET_ARCH_VARIANT
DEVICECFLAGS="-march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp"
# This specifies optimization level used during compilation. Usually it's a good idea to keep it on "-O2" for best results, but you may want to experiment with "-Os", "-O3" or "-Ofast"
OLEVEL="-O2"
# This specifies extra optimization flags, which are not selected by any of optimization levels chosen above
# Please notice that they're pretty EXPERIMENTAL, and if you get any compilation errors, the first step is experimenting with them or disabling them completely, you may also want to try different O level
OPTICFLAGS="-s -flto=8 -ffunction-sections -fdata-sections -fvisibility=hidden -funswitch-loops -frename-registers -frerun-cse-after-loop -fomit-frame-pointer -fgcse-after-reload -fgcse-sm -fgcse-las -fweb -ftracer -fstrict-aliasing"
# This specifies extra linker optimizations. Same as above, in case of problems this is second step for finding out the culprit
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--relax -Wl,--sort-common -Wl,--gc-sections"
# This specifies additional sections to strip, for extra savings on size
STRIPFLAGS="-s -R .note -R .comment -R .gnu.version -R .gnu.version_r"
# Additional definitions, which may help some binaries to work with android
DEFFLAGS="-DNDEBUG -D__ANDROID__"
##############
### EXPERT ###
##############
# This specifies host (target) for makefiles. In some rare scenarios you may also try "--host=arm-linux-androideabi"
# In general you shouldn't change that, as you're compiling binaries for low-level ARM-EABI and not Android itself
CONFIGANDROID="--host=arm-linux-eabi"
# This specifies the CROSS_COMPILE variable, again, in some rare scenarios you may also try "arm-eabi-"
# But beware, NDK doesn't even offer anything apart from arm-linux-androideabi one, however custom toolchains such as Linaro offer arm-eabi as well
CROSS_COMPILE="arm-linux-androideabi-"
# This specifies if we should also override our native toolchain in the PATH in addition to overriding makefile commands such as CC
# You should NOT enable it, unless your makefile calls "gcc" instead of "$CC" and you want to point "gcc" (and similar) to NDKTC
# However, in such case, you should either fix makefile yourself or not use it at all
# You've been warned, this is not a good idea
TCOVERRIDE="0"
# Workaround for some broken compilers with malloc problems (undefined reference to rpl_malloc and similar errors during compiling), don't uncomment unless you need it
#export ac_cv_func_malloc_0_nonnull=yes
############
### CORE ###
############
# You shouldn't edit anything from now on
if [ "$ADVANCED" -ne 0 ]; then # If advanced is specified, we override flags used by makefiles with our optimized ones, of course if makefile allows that
export CFLAGS="$OLEVEL $DEVICECFLAGS $OPTICFLAGS $DEFFLAGS"
export LOCAL_CFLAGS="$CFLAGS"
export CXXFLAGS="$CFLAGS" # We use same flags for CXX as well
export LOCAL_CXXFLAGS="$CXXFLAGS"
export CPPFLAGS="$CPPFLAGS" # Yes, CPP is the same as CXX, because they're both used in different makefiles/compilers, unfortunately
export LOCAL_CPPFLAGS="$CPPFLAGS"
export LDFLAGS="$LDFLAGS"
export LOCAL_LDFLAGS="$LDFLAGS"
fi
if [ ! -z "$NDK" ] && [ "$(echo $PATH | grep -qi $NDK; echo $?)" -ne 0 ]; then # If NDK doesn't exist in the path (yet), prepend it
export PATH="$NDK:$PATH"
fi
if [ ! -z "$NDKTC" ] && [ "$(echo $PATH | grep -qi $NDKTC; echo $?)" -ne 0 ]; then # If NDKTC doesn't exist in the path (yet), prepend it
export PATH="$NDKTC/bin:$PATH"
fi
export CROSS_COMPILE="$CROSS_COMPILE" # All makefiles depend on CROSS_COMPILE variable, this is important to set"
export AS=${CROSS_COMPILE}as
export AR=${CROSS_COMPILE}ar
export CC=${CROSS_COMPILE}gcc
export CXX=${CROSS_COMPILE}g++
export CPP=${CROSS_COMPILE}cpp
export LD=${CROSS_COMPILE}ld
export NM=${CROSS_COMPILE}nm
export OBJCOPY=${CROSS_COMPILE}objcopy
export OBJDUMP=${CROSS_COMPILE}objdump
export READELF=${CROSS_COMPILE}readelf
export RANLIB=${CROSS_COMPILE}ranlib
export SIZE=${CROSS_COMPILE}size
export STRINGS=${CROSS_COMPILE}strings
export STRIP=${CROSS_COMPILE}strip
if [ "$TCOVERRIDE" -eq 1 ]; then # This is not a a good idea...
alias as="$AS"
alias ar="$AR"
alias gcc="$CC"
alias g++="$CXX"
alias cpp="$CPP"
alias ld="$LD"
alias nm="$NM"
alias objcopy="$OBJCOPY"
alias objdump="$OBJDUMP"
alias readelf="$READELF"
alias ranlib="$RANLIB"
alias size="$SIZE"
alias strings="$STRINGS"
alias strip="$STRIP"
fi
export CONFIGANDROID="$CONFIGANDROID"
export CCC="$CC $CFLAGS $LDFLAGS"
export CXX="$CXX $CXXFLAGS $LDFLAGS"
export SSTRIP="$STRIP $STRIPFLAGS"
echo "Done setting your environment"
echo
echo "CFLAGS: $CFLAGS"
echo "LDFLAGS: $LDFLAGS"
echo "CC points to $CC and this points to $(which "$CC")"
echo
echo "Use \"\$CC\" command for calling gcc and \"\$CCC\" command for calling our optimized CC"
echo "Use \"\$CXX\" command for calling g++ and \"\$CCXX\" for calling our optimized CXX"
echo "Use \"\$STRIP\" command for calling strip and \"\$SSTRIP\" command for calling our optimized STRIP"
echo
echo "Example: \"\$CCC myprogram.c -o mybinary && \$SSTRIP mybinary \""
echo
echo "When using makefiles with configure options, always use \"./configure \$CONFIGANDROID\" instead of using \"./configure\" itself"
echo "Please notice that makefiles may, or may not, borrow our CFLAGS and LFLAGS, so I suggest to double-check them and eventually append them to makefile itself"
echo "Pro tip: Makefiles with configure options always borrow CC, CFLAGS and LDFLAGS, so if you're using ./configure, probably you don't need to do anything else"
Temporary replacement for cc.sh, as dropbox will be up soon.
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
sfortier said:
Hi!
Great info.
To cross compile some packages with autotools (./configure; make; make install) it's needed to export the SYSROOT path ($ndkTC/sysroot) and include the option --sysroot=$SYSROOT on CFLAGS. Some need too --with-sysroot=$SYSROOT as configure option. This way the configure script and linker can find the libraries.
If i'm building a library that must be used as dependence to other program I use to include --static to build a static library and --prefix=$SYSROOT/usr on configure options to install the lib on toolchain sysroot folder...
Thanks.
Click to expand...
Click to collapse
Hey.
Nice to know, I'll update my script with that. Thanks!
My last attempt to cross compile something was qemu (i'm was thinking on run windows on my tablet... )
I needed to build glib, pixmap, libpng, zlib, libjpeg-turbo, libiconv, libffi, libintl. Now I have my toolchain with all these usefull static (I prefer static libs to simplify binary installation) libs installed!
This is a general open source linux development thread!
Android's kernel is a derivative of linux's kernel. Its good to know how to build both of these kernels. You might be already familiar with building kernels for various devices from sources. So I have made a new thread for guiding people on how to compile linux kernel from source (example taken as ubuntu kernel).
Requirements:
Any linux os x64 bit(example here: ubuntu 14.04)
Git (sudo apt-get install git)
Minimum of 4GB RAM and some reasonable linux-swap
To get the currently running kernel image, type the following:
Code:
apt-get source linux-image-$(uname -r)
Now we need to obtain Ubuntu Kernel Sources from its repositories. Make a new directory and inside it, initialise the git and clone the repository.
Code:
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-<release>.git
<release> : Type in the required source. It can be lucid, precise, trusty, utopic etc.
Setting up the build environment. There are lots of tools and packages that are very much essential for building a kernel. These tools can be downloaded as a whole bundle and can be installed easily. Here's the code to set it up:
Code:
sudo apt-get build-dep linux-image-$(uname -r)
NOTE: The above comand can be executed only after you obtain the currently running kernel image. I have already given the code to obtain it above.
Now, change directory to the root of the kernel and type the following:
Code:
chmod -R a+x *
The above code will set the required permissions for building and executing the kernel.
Now, run these two commands:
Code:
fakeroot debian/rules clean
fakeroot debian/rules editconfigs
The first command cleans up the code automatically.
The slightly tricky part is with the second line of the code. When you execute it, you will have to edit a series of menuconfigs. To make changes to the configuration file we need to edit the configuration file. The kernel developers have created a script to edit kernel configurations which has to be called through the debian/rules makefile, unfortunately you will have to go through all the flavors for this script to work properly. The script will ask you if you want to edit the particular configuration. You should not make changes to any of the configurations until you see your wanted flavour configuration
We have now covered about 70% of progress. The rest is building the kernel and testing it.
Building the kernel is quite easy. Change your working directory to the root of the kernel source tree and then type the following commands:
Code:
fakeroot debian/rules clean
fakeroot debian/rules binary-headers binary-generic
If the build is successful, a set of three .deb binary package files will be produced in the directory above the build root directory. For example after building a kernel with version "3.13.-0.35" on an amd64 system, these three .deb packages would be produced:
Code:
cd ..
ls *.deb
linux-headers-3.13.0-35_3.13.0-35.37_all.deb
linux-headers-3.13.0-35-generic_3.13.0-35.37_amd64.deb
linux-image-3.13.0-35-generic_3.13.0-35.37_amd64.deb
Testing the new kernel
Install the three-package set (on your build system, or on a different target system) with dpkg -i and then reboot:
Code:
sudo dpkg -i linux*3.13.0-35.37*.deb
sudo reboot
Guys, I hope I have made an easy tutorial. You are always welcome to ask doubts (even on PM). Thank You.
Specific Hardware/Architecture
Creating a new config
I’ll be using the method of creating a new flavour, this adds a bit more work but this way you can always compile the original kernels.
We’ll use the generic flavour as the base for our own flavour being i7, this extension needs to be in small caps.
Code:
cp debian.master/config/amd64/config.flavour.generic debian.master/config/amd64/config.flavour.i7
fakeroot debian/rules clean
debian/rules updateconfigs
To make changes to the configuration file we need to edit the configuration file. The kernel developers have created a script to edit kernel configurations which has to be called through the debian/rules makefile, unfortunately you will have to go through all the flavours for this script to work properly.
Code:
debian/rules editconfigs
The script will ask you if you want to edit the particular configuration. You should not make changes to any of the configurations until you see the i7 configuration
Code:
Do you want to edit config: amd64/config.flavour.i7? [Y/n]
Make your changes, save the configuration and then keep going until the script ends.
When you’re done, make a backup of the config flavor file.
Code:
cp debian.master/config/amd64/config.flavour.i7 ../.
Now we need to clean up the git tree in order to get ready for compilation.
Code:
git reset --hard
git clean -df
Getting ready for compilation
Because we are going to be creating a new flavour based on a existing flavour (generic in my case) we need to create some extra files. During compilation the process checks the previous release for some settings, as we’re creating a local flavour it doesn’t exist in the source, so we’re creating it.
To see the previous release we use:
Code:
ls debian.master/abi
cp debian.master/abi/3.0.0-12.20/amd64/generic debian.master/abi/3.0.0-12.20/amd64/i7
cp debian.master/abi/3.0.0-12.20/amd64/generic.modules debian.master/abi/3.0.0-12.20/amd64/i7.modules
Copy our flavored configuration file back.
Code:
cp ../config.flavour.i7 debian.master/config/amd64/
We need to edit some files:
File: debian.master/etc/getabis
Search for the line:
Code:
getall amd64 generic server virtual
Change it in:
Code:
getall amd64 generic server virtual i7
File: debian.master/rules.d/amd64.mk
Search for the line:
Code:
flavours = generic server virtual
Change it in:
Code:
flavours = generic server virtual i7
File: debian.master/control.d/vars.i7
This files does not exist and in order to make the compilation process aware of our own flavor we want to compile we need to create it.
Code:
cp debian.master/control.d/vars.generic debian.master/control.d/vars.i7
You can edit the file and make it your own.
Code:
arch="i386 amd64"
supported="i7 Processor"
target="Geared toward i7 desktop systems."
desc="x86/x86_64"
bootloader="grub-pc | grub-efi-amd64 | grub-efi-ia32 | grub | lilo (>= 19.1)"
provides="kvm-api-4, redhat-cluster-modules, ivtv-modules, ndiswrapper-modules-1.9"
We need to commit our changes in the git repository.
Code:
git add .
git commit -a -m "i7 Modifications"
The text after -m is the message you add to your commit.
Compilation
It’s finally time for compiling, to keep our newly created branch in pristine condition we will do the compilation in a separate branch. We keep our branch clean as this will help later on when we want to update our new branch to a newer kernel.
Code:
git checkout -b work
fakeroot debian/rules clean
All the packages will be created in the directory /d1/development/kernel/ubuntu/oneiric
Create independent packages:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-indep
The above statement will create the following deb files:
Code:
linux-doc_3.0.0-13.21_all.deb
linux-headers-3.0.0-13_3.0.0-13.21_all.deb
linux-source-3.0.0_3.0.0-13.21_all.deb
linux-tools-common_3.0.0-13.21_all.deb
Create the tools package:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-perarch
The above statement will create the following deb file:
Code:
linux-tools-3.0.0-13_3.0.0-13.21_amd64.deb
Create the flavour depended files:
Code:
skipabi=true skipmodule=true fakeroot debian/rules binary-i7
The above statement will create the following deb files:
Code:
linux-headers-3.0.0-13-i7_3.0.0-13.21_amd64.deb
linux-image-3.0.0-13-i7_3.0.0-13.21_amd64.deb
Installation
After the compilation is finished we’ll have the above packages in the parent directory.
To install the files
Code:
cd ..
sudo dpkg -i linux-headers-3.0.0-13-i7_3.0.0-13.21_amd64.deb linux-headers-3.0.0-13_3.0.0-13.21_all.deb linux-image-3.0.0-13-i7_3.0.0-13.21_amd64.deb
Check your bootloader if the newly installed Ubuntu kernel is the default one, for grub check the file /boot/grub/menu.lst or if you run grub2 check /boot/grub/grub.cfg
thx for your info
nice job mate..!! :good:
now i'm gonna try this..!!
Nice ,i can't say anything
faizauthar12 said:
Nice ,i can't say anything
Click to expand...
Click to collapse
Thank you for the great guide!!!
Nice thread. I'll try it at home
Thanks
Enviado de meu Moto G usando Tapatalk
Thx for the guide
tra_dax
To research a way to "Run a Linux distro natively" on the Galaxy Tab3 10.1.
XDA:DevDB Information
Run a Linux distro natively, Tool/Utility for the Samsung Galaxy Tab 3 10.1
Contributors
r2d23cpo, CalcProgrammer1, moonbutt74, Angel_666
Version Information
Status: Testing
Created 2015-01-21
Last Updated 2015-02-08
reserved
Wao I wrote a nice introduction and posted on first post and after I edited the project every is gone. So I will post down here something again.
For now I will research the possibility of adapting Kexecboot to our X86 device.
Kexecboot is a program that implements a second-stage bootloader using a stripped-down Linux and the 'kexec' feature to boot into the final running Linux image.
Click to expand...
Click to collapse
Please do search in youtube for kexecboot there are a number of short videos.
h__p://kexecboot.org link not working today
Did some search for you and here are the top ones on XDA.
Kexecboot on the TF700t(TF700t-AKBI v2.6.5) by @workdowg
http://forum.xda-developers.com/showthread.php?t=2387133
[BOOT] Kexecboot / CM-Recovery by @threader
http://forum.xda-developers.com/showthread.php?t=2520663
[DEV/WIP] Kexecboot Bootloader for Galaxy Note 3 N900T - Boot Multiple Kernels by @CalcProgrammer1
http://forum.xda-developers.com/not.../dev-wip-kexecboot-bootloader-galaxy-t2864109
[BOOTLOADER]KexecBoot - A graphical kernel bootloader[Ver: 14Nov2014] by @apapousek
http://forum.xda-developers.com/ico...ootloader-kexecboot-graphical-kernel-t2937006
Improve kexecboot
http://elinux.org/Improve_kexecboot
Now I had started to search and I think I found that Tasssadar/multirom is base in kexecboot. This could be even better, maybe we can convince @Tasssadar to help us create Multirom for the TAB3!
So here is a link to his thread
[MOD][JAN 15] MultiROM v30 [email protected]
http://forum.xda-developers.com/showthread.php?t=2011403
Hopefully the see their mention here and give us a hand by pointing us out where to start.
Step one is to get a kexec-capable kernel working. Kexecboot is just a frontend for kexec. There are two options - normal kexec and kexec-hardboot. I managed to make hardboot work with the Note 1 using some patches but haven't been successful with either on the Note 3. I don't know about this device but if it is x86 then hardboot is likely out as it has ARM-only patches. Then again, if it's x86 you may be able to use GRUB or something. Reading the GSMArena page for the Tab3 says Marvell ARM7 with PowerVR though. In that case you can forget GPU acceleration ever being an option as right now there is no X11/Mesa capable PowerVR driver nor is there a development effort for one.
@CalcProgrammer1 and others
I do really appreciate your comments. Please forgive my ignorance in this area. I am about to say some stupiditty. jijijiji. I see you have point some concerned about " PowerVR" and "GPU acceleration". I just want to boot into Linux Distro as best at it can. Acceleration of any kind is not a priority. But if any driver limitation prevent us from displaying in a std mode then that can be a show stop.
I understood you say
Code:
Step one is to get a kexec-capable kernel working. Kexecboot is just a frontend for kexec..
1-Our Samsung Tab3 10.1 "OS Open source" is incomplete, that is why CM11 has been to slow on release. Still guys at "[SIGNUP] [DEVELOPMENT] signup sheet for aosp build team" had work hard to produce a pre-alpha.
2-Good news is that Open Source for the Kernel works fine.
So can you pointing me in the right direction. How to build this " kexec-capable kernel". I had play with kernel build and even added some missing modules to have CIFS capability. SO compiling Kernel should not be hard for me.
Clearly adding "kexec" may not bee that easy. I am hoping to see an option in the building process.
Code:
kexec is a system call that enables you to load and boot into another kernel from the currently running kernel.
I had played some what with boot.img initramfs and hacked /init to do perform similar task.
Code:
!/sbin/busybox sh
# initramfs pre-boot init script
# Mount the /proc and /sys filesystems
/sbin/busybox mount -t proc none /proc
/sbin/busybox mount -t sysfs none /sys
/sbin/busybox mount -t tmpfs none /dev
# Something (what?) needs a few cycles here
/sbin/busybox sleep 1
# Populate /dev
/sbin/busybox mdev -s
# Mount the root filesystem, second partition on micro SDcard
/sbin/busybox mount -t ext4 -o noatime,nodiratime,errors=panic /dev/mmcblk1p2 /data/local/mnt/ubuntu
# Clean up
/sbin/busybox umount /proc
/sbin/busybox umount /sys
/sbin/busybox umount /dev
# Transfer root to SDcard
[COLOR="Red"]exec[/COLOR] /sbin/busybox [COLOR="Red"]switch_root[/COLOR] /data/local/mnt/ubuntu /etc/init.stage1]
This is a C& P from =>
As you see I take the second partition in External SDCARD "/dev/mmcblk1p2" and mounted in "/data/local/mnt/ubuntu" and transfer to a secondary init in Ubuntu with "exec switch root".
Code:
[COLOR="Red"]exec[/COLOR] /sbin/busybox [COLOR="Red"]switch_root [/COLOR]/data/local/mnt/ubuntu /etc/init.stage1
I guess this exec switch root is performing similar function as "kexec"
Can we work with this? -> Edited: I had already compile kexec in kernel.
Any help will be really really appreciated. Thanks.
@CalcProgrammer1
Ok
First step DONE!
I had compiled a new kernel with kexec. kexec stock from Kernel, just enabled. Do not know about hardboot but willing to see the patch!.
Listen Arm/mips/x86 should be the same kernel(clearly on same kernel number!). So, arm should not matter. Any way the code for kexec seems small enogth to compare with yours.
One thing I have to mention I am working with 4.2.2 since it is less molested by SELinux protection.
What is next step? Pleaseeeeeee.
@JoinTheRealms @cogano @jcfunk any kexec help or advice for these guys?
@workdowg @JoinTheRealms @cogano @jcfunk
Wao pretty nice string of mention jijiji. Do not feel obligated, but any help really appreciated.
Listen guys do not feel ignore but since @CalcProgrammer1 first approach me, I am trying to follow his work at [UTIL] Kexecboot Bootloader for Galaxy Note i717 - Boot Multiple Kernels. Still I you point me to another one I will gladly read on it.
So I build a kernel with kexec enabled! Will that maters or I need to compile one kexec from source?
Next I had downloaded your kernel_kexecboot_quincyatt_v2.zip and open the initramfs. Also compare it to your source. Looks similar. I see I need the following files:
Code:
ramdisk/bin/busybox need to veryfy my busybox compitibility but ok in general
ramdisk/bin/[COLOR="Blue"]kexecboot[/COLOR]
ramdisk/bin/[COLOR="Blue"]lvm[/COLOR]
ramdisk/bin/sh->busybox should be ok
ramdisk/bin/[COLOR="Blue"]tssrv[/COLOR]
ramdisk/sbin/kexec
ramdisk/sbin/[COLOR="Blue"]refresh[/COLOR]
ramdisk/init -> it is a sh script ok
So assuming my enabled kexec is ok for now, I also need to compiled kexecboot, lvm, tssrv, refresh but I have no source for lvm, tssrv, refresh.
Where can I get sources for: lvm, tssrv, refresh? I will check if lvm and tssrv may be part of any busybox, toolbox or recovery I have around.
Files from CalcProgrammer1 project "[UTIL] Kexecboot Bootloader for Galaxy Note i717 - Boot Multiple Kernels."
h__ps://github.com/CalcProgrammer1/kernel_quincyatt_kexec
h__ps://mega.co.nz/#F!0ct3EaTD!wHWnGo1M_2smyKdzGMIYmw
r2,
chroot to your distro and run in terminal
apt-get update
apt-get install gcc gcc-4.7
check /etc/apt/sources.list to see if you have source repositories entries, for example [in debian]
deb-src http://ftp.us.debian.org/debian/ wheezy main
your distro will vary, then
apt-cache search lvm <-----and so forth for every package you need from [src] and compile right on your tab natively
i've been doing this on arm, the end/native result should be similar. Be aware you may need to establish a repository locally for your
kernel source in case you need to generate headers for your toolchain
cd [kernel-source-$TOP]
make mrproper
make ARCH=x86 [correct_defconfig]
make ARCH=x86 headers_check
make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install
with your mount points correct for your ubuntu project you should be able to do all that via terminal.
m
r2d23cpo said:
So assuming my enabled kexec is ok for now, I also need to compiled kexecboot, lvm, tssrv, refresh but I have no source for lvm, tssrv, refresh.
Where can I get sources for: lvm, tssrv, refresh? I will check if lvm and tssrv may be part of any busybox, toolbox or recovery I have around
Click to expand...
Click to collapse
You don't need them. My sloppy work is showing lol. I took most of that from another kexecboot from the HP TouchPad. Chances are your Tab3 doesn't use LVM, though the TouchPad did so that's where that came from. You can remove it.
The tssrv binary is the userspace HP TouchPad touchscreen driver. Most tablets and phones have a kernelspace touchscreen driver, so you can just remove this (plus kexecboot isn't touch driven anyways).
Refresh was something I was testing for my Note 3, as it uses a software-refreshed panel. If your Tab3 uses a video mode panel you won't need a software refresher but if it does, well, you may run into an issue that I don't know about as refreshing seems SoC-specific and I'm only used to Qualcomm chips. Remove it for now as well.
Wao spent over 18 consecutive hours, I had to sleep. I had trouble always with this so call automatic makefile that never work!! It is simpler to create my own makefile and adjust, ad subtract commands as it show error.
So I am working. just having some programing issues that do not let me go at a better speed. See you latter friends.
IMPORTANT:
PLEASE if you downloaded the zimage I have previously gave link, DO NOT USED IT.
Yes it has KEXEC Enabled 100%. BUTTTTT, I did something wrong in the selection that prevent WIFICommunication!!! You been warned. If you had such an accident, Use Odin To reinstall a good Booot Image or a zip package using the External SDCARD. If You need help please ask. But As I said I am going to sleep now.
r2d23cpo said:
Wao I wrote a nice introduction and posted on first post and after I edited the project every is gone. So I will post down here something again.
For now I will research the possibility of adapting Kexecboot to our X86 device.
Please do search in youtube for kexecboot there are a number of short videos.
h__p://kexecboot.org link not working today
Did some search for you and here are the top ones on XDA.
Kexecboot on the TF700t(TF700t-AKBI v2.6.5) by @workdowg
http://forum.xda-developers.com/showthread.php?t=2387133
[BOOT] Kexecboot / CM-Recovery by @threader
http://forum.xda-developers.com/showthread.php?t=2520663
[DEV/WIP] Kexecboot Bootloader for Galaxy Note 3 N900T - Boot Multiple Kernels by @CalcProgrammer1
http://forum.xda-developers.com/not.../dev-wip-kexecboot-bootloader-galaxy-t2864109
[BOOTLOADER]KexecBoot - A graphical kernel bootloader[Ver: 14Nov2014] by @apapousek
http://forum.xda-developers.com/ico...ootloader-kexecboot-graphical-kernel-t2937006
Improve kexecboot
http://elinux.org/Improve_kexecboot
Now I had started to search and I think I found that Tasssadar/multirom is base in kexecboot. This could be even better, maybe we can convince @Tasssadar to help us create Multirom for the TAB3!
So here is a link to his thread
[MOD][JAN 15] MultiROM v30 [email protected]
http://forum.xda-developers.com/showthread.php?t=2011403
Hopefully the see their mention here and give us a hand by pointing us out where to start.
Click to expand...
Click to collapse
Congratulations, it´s a very useful idea and i hope it gets developed Good luck!
Good morning Folks! It is 12:07AM in the Atlantic Zone with a nice star sky.
So after 322 views and 11 replys @rjmm13 is our first non-developer that had show and post interest. Congratulations! [Applause ]
And we are ready do some more tests today.
To my friends with the right knowledge I need the full kexec instruction I will use to boot Ubuntu. From the Ubuntu manuals it seems some thing like:
Code:
kexec -l /boot/vmlinux --append=root=/dev/hda1 --initrd=/boot/initrd
For now I am using @CalcProgrammer1 work on Galaxy Note i717. init shows he mounted proc, sys & dev. I had place or should I say extracted Ubuntu in my 2nd ext4 partition on the external SdCard or partition "/dev/mmcblk1p2" So I guess my command should look like
Code:
kexec -l /boot/vmlinux --append=root=/dev/mmcblk1p2 --initrd=/boot/initrd
But I wonder, that partition is not mounted!!!! Or I am wrong.
My other Option will be to mount mmcblk1p2 in /data/local/mnt/ubuntu
Then partial code may looks like:
Code:
busybox mount -t ext4 /dev/block/mmcblk1p2 /data/local/mnt/ubuntu
kexec -l /boot/vmlinux --append=root=/data/local/mnt/ubuntu --initrd=/boot/initrd
So witch one is the good command sequence?
------------------------------------------------------------------------------
Edited.
To @moonbutt74 I have not ignored you in try to build on same TAB3 device. But If I do then I will have to worry about backing up every time I have to do test on TAB3!!
Listen I am having troubles compiling automated makefiles. So I recall your comments. And I am up to building kexec-tools with same Ubuntu deb packages. That should be pretty easy.
I have Ubuntu amd64 desktop but I will try to install i386 debs for maximum compatibility! Just as a test.
Code:
apt-get update
apt-get install kexec-tools_2.0.2-3ubuntu4_i386
Do you know if there is a way to then force my out kernel source to used Ubuntu Desktop files? I know may sound stupid.
Now regards
Code:
cd [kernel-source-$TOP]
make mrproper
make ARCH=x86 [correct_defconfig]
make ARCH=x86 headers_check
make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install
What "make mrproper" commads do?
What "correct_defconfig" do you used?
"make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install" I do not recalled doing this And I compiled it ok. What the kernel sources ask was to edit a config file and add my tool location?
Thanks body. Take your time I know you are busy in your own projects.
I am doing it again, making a full conversation my self! jijijiji
@moonbutt74 you are genius, if I run Ubuntu in a VNC server in TAB3, I can work in my PC. And walaaaaa! I am in fact running from external sdcard partition. I do not have to worry about backup!!! As always you are the man.
With the advantage that the code generated by Ubuntu should be 100% compatible with TAB310.1 x86.
In the future I do really have to look more deep in your comments.
I will test to see how it goes.
I waist 7 hours doing some needed backup, my desktop was getting low in memory. Almost lost my files due to corruption. But I am back.
So I tested leaving the tablet as Ubuntu VNC Server and works but I still think is slow. But I do not need VNC.!!! Nor the GUI.
I had recall installing "shh" previously in my Ubuntu, So I can just do Putty "shh" in Win7 and it works much better!!! In fact I can just use WinSCP also to even load or take files easily from the TAB3 Ubuntu system file. Thanks body for the Idea.
Now then I will start doing what you did a week ago, Installing inside the Tab310.1 the SDK toolchain, platform and the Kernel source just in case I need it. I know I am continue wasting more time without doing real-work on kexecboot. But if it works I will improve my developing speed in the future. I hope to report soon.
r2d23cpo said:
Code:
kexec -l /boot/vmlinux --append=root=/dev/mmcblk1p2 --initrd=/boot/initrd
But I wonder, that partition is not mounted!!!! Or I am wrong.
My other Option will be to mount mmcblk1p2 in /data/local/mnt/ubuntu
Then partial code may looks like:
What "make mrproper" commads do?
What "correct_defconfig" do you used?
"make ARCH=x86 [your toolchain's correct location for]/sysroot/usr headers_install" I do not recalled doing this And I compiled it ok. What the kernel sources ask was to edit a config file and add my tool location?
Thanks body. Take your time I know you are busy in your own projects.
Click to expand...
Click to collapse
1. The root= option will automatically mount that given device as the root partition (aka /). If you use root= you do not need an initramfs at all, because the kernel will mount the partition and run the /init script automatically. If you don't use a root= command or wish to run more complex boot sequences, then you will need an initramfs. In that case, the initramfs gets mounted as / and then must do its own work to mount the real root partition and do switch_root to replace the temporary initramfs root with the new proper root partition.
2. "make mrproper" is a better version of "make clean". It basically resets your entire kernel build to a clean state. Do this if you want to make sure your build is pure rather than reusing already-compiled temporary files.
3. You must create your own defconfig since you're using a new device. Use make menuconfig to edit your .config file to how you like it, then copy it to arch/<architecture>/configs/your_defconfig_name and then you will be able to use make your_defconfig_name to setup your .config file each time you want to rebuild it. I think x86 is "i386" in the tree, ARM is "arm".
4. If you're building for an x86 device on another x86 device you should just be able to make without the ARCH or CROSS_COMPILE flags. If you're using an x86_64 machine you'll want to set up a 32-bit chroot or something though if you want to build a 32-bit kernel. If you're building for ARM on an x86/amd64/anything-else-not-arm machine then you have to do ARCH=arm CROSS_COMPILER=name-of-your-arm-toolchain- so it builds it with the cross compiler.
@CalcProgrammer1
The following Is NOT a correction Nor disputing your comments. Please continue helping. If I write is to clarify what is my understanding.
I am lost in #1. I bet you are trying to explain what my options are by using "root=". Still it get me confuse. But listen what I need is the following. We has said that Kexecboot is a front end of kexec. So what I want is to test kexec first ALONE so see how it behaves. For that I need the correct kexec construction sentence to call Ububtu in the secon partiyion of the SDCARD. So I look in the kexec manual an I got what I wrote before. Now I am asking you if you know or you can look at your Kexec config file for that sentence. I hope you understand me now.
#2 is a nice explanation. I see. Thanks
#3 Open Source instruction said to use "android_santos10_open_r00_user_defconfig" But I agree with you, So what I did I use instead was "make ARCH=i386 android_santos10_open_r00_eng_defconfig" Then "make menuconfig" and went and try to enable what I needed. Basically verify the kexec was enabled, and that my CIFS was also enabled. Still I learn to copy ".config" and place it a my future config with a different name. Thanks.
#4 I tend to agree with you some what in that the x86 binary code of my Ubuntu Desktop may work in the x86 tablet. Well that is almost the case. As an example I downloaded the Open Office Ubuntu deb package for x86 desktop and then installed in the tablet. 100% working. But some of binary code compiled not always work. Yes my Ubuntu Desktop is x86 64. And I bet you that if the code gets generated for 64 bit I am not sure is it will work. Then the other factor I think is the possibility of missing libraries that Ubuntu desktop my have against Android minimal system.
Now You raise a good point, I could run a chroot Ubuntu x86 ( not 64). But then again It is simpler to have another partition and run Grub2 with Ubuntu x86 without any chroot. That is what I did normally. But I have 1.5 tetra of garbage. I am in the process of backing up, so that I can liberate HD space.
Regards "CROSS_COMPILER" jijiji yes it seems funny. But the real answer is that it is false that the process do "CROSS_COMPIling". That statement just select the toolchain to use. It does not matter if it is mips, arm or Intel. Just point to the place of the toolchain. The the output clearly is going to be the output for what the toolchain was build for.
So Can you look at your kexecboot config and tell me if the command is there.
By the way The Documentation for Kexecboot at "http://kexecboot.org" is no longer available. It seem that the site is dead. In fact many others related to kexecboot are dead too!!. So I ask you for any chance did you save that documentation? Can I have it?
Thanks body I really appreciate your
PD, I am Create a kernel in my desktop (i7 8core), but I have to mention that I did not include V8, so I guess it used 1 or 2 cores only. It took 25 minutes. I am compiling the kernel also in my Tab3. It has pass 1 hour and I guess is half way!!
But, I had 2 outages of electrical power! My Tab3 is unaffected to outages of power jijijiji. This is why I want to have Linux natively. This is weird It never happens. I guess there have to be a construction near by that require the cut of power.
hey guys,
just a quick note in reference to,
4. If you're building for an x86 device on another x86 device you should just be able to make without the ARCH or CROSS_COMPILE flags.
Click to expand...
Click to collapse
that is true if you are building/compiling natively on this tab. However if you are compiling on a pc [x86][x86_64} you do need to cross compile and pass flags.
The reason is you need to link [for some reason] with ld.gold for the binary to execute else you get the bad/incorrect/invalid magic error.
If building on pc for this tab through buildroot set arch for i386 and arch variant for i686. for building through gcc on your own makefile recipe
you will need to pass the following flags for CFLAGS , CXXFLAGS and LDFLAGS ; -m32 -static, and pass/export ARCH=x86,this goes for building on 32bit or 64bit pc.
m
moonbutt74 said:
...If building on pc for this tab through buildroot set arch for i386 and arch variant for i686. for building through gcc on your own makefile recipe you will need to pass the following flags for CFLAGS , CXXFLAGS and LDFLAGS ; -m32 -static, and pass/export ARCH=x86,this goes for building on 32bit or 64bit pc....
Click to expand...
Click to collapse
Nicessss, I was looking for that. So it does not requires the "toolchain" other that really compiling on a desire vesrion number. Did I understood correct or I need to setup toolchain some where? What about gcc on the Ubuntu?
What I do is create my own Makefile like
Code:
NDKROOT=/home/<username>/bin/androidndk
NDKSYSROOT=$(NDKROOT)/platforms/android-8/arch-x86
TOOLCHAIN := $(NDKROOT)/toolchains/x86-4.6/prebuilt/linux-x86
CC := $(TOOLCHAIN)/bin/i686-linux-android-gcc
#INCLD_DIR := $(TOOLCHAIN)/usr/include
INCLD_DIR := $(TOOLCHAIN)/include
LIB_DIR := $(TOOLCHAIN)/lib
#LIBS = -L$(LIB_DIR)
TARGET := kexecboot
#CFLAGS := -Wall
CFLAGS = -DNO_MNTENT -UHAVE_ICONV -DNO_MALLINFO=1 \
--sysroot=$(NDKSYSROOT) \
-isystem $(NDKSYSROOT) \
-I$(NDKSYSROOT)/usr/include \
-mandroid \
-D_GNU_SOURCE=1 \
-L$(NDKSYSROOT)/usr/lib
# -I$(NDKSYSROOT)/usr/include/sys \
# -I$(NDKSYSROOT)/usr/include/linux \
LDFLAGS := -L$(TOOLCHAIN)/lib -Wl,-rpath-link $(TOOLCHAIN)/lib
SRCS := $(TARGET).c util.c cfgparser.c devicescan.c evdevs.c fb.c gui.c \
menu.c xpm.c rgb.c tui.c fstype/fstype.c machine/zaurus.c
OBJS := $(TARGET).o util.o cfgparser.o devicescan.o evdevs.o fb.o gui.o \
menu.o xpm.o rgb.o tui.o fstype.o
#OBJS := util.o cfgparser.o devicescan.o evdevs.o fb.o gui.o \
# menu.o xpm.o rgb.o tui.o fstype.o zaurus.o
LIBS := -L$(LIB_DIR)
#-lutil -lpthread
$(TARGET): $(OBJS)
# $(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(LIBS) $(TARGET).c -o $(TARGET)
$(CC) $(CFLAGS) $(LDFLAGS) $(OBJS) $(LIBS) -o $(TARGET)
$(TARGET).o: $(TARGET).c $(TARGET).h
$(CC) $(CFLAGS) -c $(TARGET).c
util.o: util.c util.h
$(CC) $(CFLAGS) -c util.c
cfgparser.o: cfgparser.c cfgparser.h
$(CC) $(CFLAGS) -c cfgparser.c
devicescan.o: devicescan.c devicescan.h
$(CC) $(CFLAGS) -c devicescan.c
evdevs.o: evdevs.c evdevs.h
$(CC) $(CFLAGS) -c evdevs.c
fb.o: fb.c fb.h
$(CC) $(CFLAGS) -c fb.c
gui.o: gui.c gui.h
$(CC) $(CFLAGS) -c gui.c
menu.o: menu.c menu.h
$(CC) $(CFLAGS) -c menu.c
xpm.o: xpm.c xpm.h
$(CC) $(CFLAGS) -c xpm.c
rgb.o: rgb.c rgb.h
$(CC) $(CFLAGS) -c rgb.c
tui.o: tui.c tui.h
$(CC) $(CFLAGS) -c tui.c
fstype.o: fstype/fstype.c fstype/fstype.h
$(CC) $(CFLAGS) -c fstype/fstype.c
#zaurus.o: machine/zaurus.c machine/zaurus.h
# $(CC) $(CFLAGS) -c machine/zaurus.c
clean:
rm -f *.o *~ $(TARGET)
By the way, my Kernel Build took 2 hours on the TAB310.1. Now I need to test it.
r2,
hi,
if compiling on the tab for the tab [natively through tab's ubuntu distro], compile straight and you should be good to go.
if compiling outside the tab [host/build] for the tab [target] [cross compile], then yes you need to pass flags and such.
For my experiments when i had the tab, i first built my toolchain through the 32bit version of android ndk and geared to
jellybean api.
In my makefile the flags i included were
CFLAGS := -m32
LDFLAGS := -static <------this is/can be optional, i like static binaries for portability reasons.
on -Wall , i usually leave that on.
on -werror, i usually turn that off.
m
Wao still tryint to leave the Starting Line but one after the other. jijiji
But Good news. To strip out all problems I decided to start from scrach. And after loking at the config as it is I found that kexec was set to enable from the beguining.
hsbadr said in his thread [KERNEL] [KEXEC] Kernel EXECution for locked devices [N900V] [WIP] to check kexec by doing cat /proc/kallsyms | grep kexec
and here is the output of the system calls:
Code:
[email protected]:/ # cat /proc/kallsyms | grep kexec
00000000 t machine_kexec_page_table_set_one
00000000 t machine_kexec_free_page_tables
00000000 T machine_kexec_prepare
00000000 T machine_kexec_cleanup
00000000 T machine_kexec
00000000 T log_buf_kexec_setup
00000000 W compat_sys_kexec_load
00000000 t kexec_crash_loaded_show
00000000 t kexec_loaded_show
00000000 t kexec_crash_size_store
00000000 t kexec_crash_size_show
00000000 T kexec_should_crash
00000000 T sys_kexec_load
00000000 T crash_kexec
00000000 T kernel_kexec
00000000 d kexec_loaded_attr
00000000 d kexec_crash_loaded_attr
00000000 d kexec_crash_size_attr
00000000 d event_exit__kexec_load
00000000 d event_enter__kexec_load
00000000 d __syscall_meta__kexec_load
00000000 d kexec_mutex
00000000 d types__kexec_load
00000000 d args__kexec_load
00000000 t __event_exit__kexec_load
00000000 t __event_enter__kexec_load
00000000 t __p_syscall_meta__kexec_load
00000000 B in_crash_kexec
00000000 B kexec_crash_image
00000000 B kexec_image
[email protected]:/ #