Related
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
add.thebad said:
i am trying to edit the init.rc but have problems extracting boot.img-ramdisk.gz
i have made a rom dump
then extracted boot.img
got boot.img-ramdisk.gz so extracted that
and now i have a file called boot.img-ramdisk nothing else
so how can i edit ramdisk?
thanks in advance. any help welcome
Click to expand...
Click to collapse
add.thebad,
Been a while since I've done this, lol, but these are the instructions I followed:
http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
There's links to the Perl scripts in that page too.
Hope this helps.
Cheers!
thanks but the link to the scripts is broke. dont suppose you know where to get another
add.thebad said:
thanks but the link to the scripts is broke. dont suppose you know where to get another
Click to expand...
Click to collapse
Adam (that's right, right? ),
I found an XDA version of the "How To" link I posted above: http://forum.xda-developers.com/showthread.php?t=443994 and the files are at the bottom of the first post and they are still available.
By the way, I used these instructions (along with lots of help from Amon_RA himself) for unpacking and repacking Amon_RA's custom recovery .img file (I built a version that doesn't require the use of a trackball for the Eris).
I think after you unpack the ramdisk, you'll just replace / update your init.rc file and then repack everything before doing the mkbootfs on your ramdisk directory (followed by your particular mkbootimg command).
Good luck!
Cheers!
thanks for you help i have the scripts now and i can get it to extract however i get the error "gunzip is not recognised" and the files it does extract are emply
add.thebad said:
thanks for you help i have the scripts now and i can get it to extract however i get the error "gunzip is not recognised" and the files it does extract are emply
Click to expand...
Click to collapse
Are you on a Linux system?
The gzip / gunzip utilities should be on your system and/or referenced in you PATH environment variable.
Do a find / -name 'gzip' 2> /dev/null or find / -name gunzip 2> /dev/null or whereis gunzip or which gunzip (one of these should reveal the utility's location).
The unpack-bootimg.pl does use the gunzip command to extract the files, so you will need this utility.
Cheers!
after a bit of reading i think the way i have got my boot.img is wrong could this be why the folder is empty?
add.thebad said:
after a bit of reading i think the way i have got my boot.img is wrong could this be why the folder is empty?
Click to expand...
Click to collapse
Not sure... Like I said, I started with a known, good recovery.img file... I never have (yet) played with a boot.img file...
scary alien said:
Not sure... Like I said, I started with a known, good recovery.img file... I never have (yet) played with a boot.img file...
Click to expand...
Click to collapse
i managed to extract a boot.img from an official system image and tried that and got the same result. could i have anything to do with gunzip not being recognised
add.thebad said:
i managed to extract a boot.img from an official system image and tried that and got the same result. could i have anything to do with gunzip not being recognised
Click to expand...
Click to collapse
lol...I think we cross-posted a little bit ago...see above ^^^ for my post about your gunzip utility.
scary alien said:
lol...I think we cross-posted a little bit ago...see above ^^^ for my post about your gunzip utility.
Click to expand...
Click to collapse
haha so we did.
no im on windows and cant get gunzip to work. think i have gzip working tho
any ideas?
add.thebad said:
haha so we did.
no im on windows and cant get gunzip to work. think i have gzip working tho
any ideas?
Click to expand...
Click to collapse
Yeah, you'll have to grab some Windows versions of the Unix commands.
I can't remember where I got mine, but a quick search yielded this as a possible starting place:
http://www.cyberciti.biz/faq/unix-command-line-utilities-for-windows/
There's a couple of links to sets of tools. After you download and install these, make sure you point / change your Windows PATH to point to the utilities or just do all of your work in the same directory.
You really just need the utilities that are referenced in the Perl script... Not sure I'd bother with the whole Cygwin thing (your call, of course).
Cheers!
scary alien said:
Yeah, you'll have to grab some Windows versions of the Unix commands.
I can't remember where I got mine, but a quick search yielded this as a possible starting place:
http://www.cyberciti.biz/faq/unix-command-line-utilities-for-windows/
There's a couple of links to sets of tools. After you download and install these, make sure you point / change your Windows PATH to point to the utilities or just do all of your work in the same directory.
You really just need the utilities that are referenced in the Perl script... Not sure I'd bother with the whole Cygwin thing (your call, of course).
Cheers!
Click to expand...
Click to collapse
Ok will try that. I allready have cygwin to try get the commands i will try ur link tho. Think im getting a bit outa my depth but ive learnt so much so far i dont want to give up so thanks for your help
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
add.thebad said:
heres where im at now. im trying to edit the init.rc
i have extracted the boot.img using unpack-bootimg.pl and have got the follwing
empty folder called ramdisk
boot.img-ramdisk.cpio.gz
boot.img-ramdisk.gz
boot.img-kernell.gz
i am now stuck extracting the ramdisk to edit init.rc
i also get error gunzip is not a recognied command
any help??
Click to expand...
Click to collapse
Well, I spent some time tonight trying to do this under Windows myself, but I used the split_bootimg.pl Perl script instead to create the *.img-kernel and *.img-ramdisk.gz files (with mixed success). lol, I had a hard time re-finding some good Unix commands that would run under Windows (I've got some good ones on my work PC, but that doesn't help me now).
Here's the relevant section in the original HOWTO link I sent you:
% ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
Now, extracting the ramdisk under Windows is a little trickier and I couldn't get the whole way there because I couldn't find the cpio command for Windows (you might have it already if you are using Cygwin). Anyway, the documentation explains that you would create a temporary "ramdisk" directory, change to it, use the gzip utility to uncompress and feed the output to the cpio command to actually extract the files and directories:
Extract the ramdisk.
% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..
That should work for you (if you have appropriate utilities) and should give you the various files that comprise the ramdisk for you to modify (i.e., the init.rc).
After modifying them, you would use the mkbootfs utility (not sure if this is actually available in Windows) to re-pack the ramdisk and then use the mkbootimg command to re-pack your boot image.
It might be easier to get a Linux distro installed that you can launch from Windows just to do this.
Good luck!
scary alien said:
It might be easier to get a Linux distro installed that you can launch from Windows just to do this.
Good luck!
Click to expand...
Click to collapse
ahaa managed to get everything extracted and edit the init.rc so thank you for all your help
one the linux side of things i have ubuntu dual boot and use it from time to time im just not familiar with the commands on it so prefer windows. might try it more oftern since it can be a pain finding all the tools for windows
ne way all i need to do now is repackage it which is proving to be a bit of a problem atm.
a sleep less night and ill c how i get on lol
cheers for the help
add.thebad said:
ahaa managed to get everything extracted and edit the init.rc so thank you for all your help
one the linux side of things i have ubuntu dual boot and use it from time to time im just not familiar with the commands on it so prefer windows. might try it more oftern since it can be a pain finding all the tools for windows
ne way all i need to do now is repackage it which is proving to be a bit of a problem atm.
a sleep less night and ill c how i get on lol
cheers for the help
Click to expand...
Click to collapse
Adam,
Glad you are making progress .
Here's the last few bits that I used to re-pack my ramdisk and to rebuild the bootable recovery .img file (i.e., ramdisk + kernel):
# pack-up the ramdisk directory's files to build the new ramdisk .zip
#
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
# now, repack the kernel and ramdisk to make the new recovery image
#
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel recovery-RA-eris-v1.6.2.img-kernel --ramdisk ramdisk-new.gz --base 0x11200000 -o new-recovery.img
This is very similar to the instructions in the HOWTO thread.
Also, note the --base parameter in the mkbootimg line, this is unique/specific to each phone/bootable image since it appears to be the boot/load address, so you'll have to know or find-out what this particular value is for your situation.
Good luck and let me know how it goes.
Cheers to you, too!
scary alien said:
Adam,
Glad you are making progress .
Here's the last few bits that I used to re-pack my ramdisk and to rebuild the bootable recovery .img file (i.e., ramdisk + kernel):
# pack-up the ramdisk directory's files to build the new ramdisk .zip
#
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
# now, repack the kernel and ramdisk to make the new recovery image
#
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel recovery-RA-eris-v1.6.2.img-kernel --ramdisk ramdisk-new.gz --base 0x11200000 -o new-recovery.img
This is very similar to the instructions in the HOWTO thread.
Also, note the --base parameter in the mkbootimg line, this is unique/specific to each phone/bootable image since it appears to be the boot/load address, so you'll have to know or find-out what this particular value is for your situation.
Good luck and let me know how it goes.
Cheers to you, too!
Click to expand...
Click to collapse
ok gave up in windows cannot find a command or perl script for mkbootfs so now in ubuntu giving it a try
i can do that first bit fine. does it need to be re cpio?
on the next commannd i type
Code:
mkbootimg --cmdline 'no_console_suspend=1 console=null' --boot.img-kernel.gz --boot.img-ramdisk.gz ----base 0x10000000 -o new-boot.img
and get this
Code:
[email protected]:~/Desktop$ mkbootimg --cmdline 'no_console_suspend=1 console=null' --boot.img-kernel.gz --boot.img-ramdisk.gz ----base 0x10000000 -o new-boot.img
usage: mkbootimg
--kernel <filename>
--ramdisk <filename>
[ --second <2ndbootloader-filename> ]
[ --cmdline <kernel-commandline> ]
[ --board <boardname> ]
[ --base <address> ]
-o|--output <filename>
but nothing is outputted on my desktop
add.thebad said:
ok gave up in windows cannot find a command or perl script for mkbootfs so now in ubuntu giving it a try
Click to expand...
Click to collapse
I believe that the mkbootfs utility is available / created as a result of building / compiling the Android open source.
Like I mentioned before, its been a while since I did all this myself, but I had to download and do the base "make" for the Android open source since I was actually changing and recompiling the custom recovery.
So, you'll need to check-out / download the desired AOSP branch / version from the proper location (which eludes me at the moment). Then, I believe doing the base / generic "make" for the AOSP will create or reveal the mkbootfs utility.
One of the threads in the following forum should have a better, starter explanation for doing the above that I could post here:
http://forum.xda-developers.com/forumdisplay.php?f=613
I'd dig into this more with you tonight, but I gotta do my taxes and then go into work for a few hours tonight (ugh on both counts, lol!).
Good luck!
NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF
hey thanks very nice guide
Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?
SammyC said:
Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?
Click to expand...
Click to collapse
I haven't try but i guess yes.
If you really want to recompile/repackage the kernel, you can refer to this http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html ; it's about the Motorola Droid, but some concepts are universal for all the android devices.
HF
Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz
Thanks - Very useful to have this in this section. I tried the example, and it all worked fine on an old Ubuntu dist.
gnufabio said:
Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz
Click to expand...
Click to collapse
Well, that's a lot easier...
I didn't know your script, thanks for sharing.
Updated the first post with a bash script to automate the entire process.
Yesterday I've succesfully recompiled the stock kernel and I'm thinking on write another guide like this one on the subject.
The process is a little complicate, i'm looking for an easy way to explain but it's hard.
Anyway I'm working on it in my spare time.
That would be great if you could.
ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions
raypou said:
ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions
Click to expand...
Click to collapse
it's exactly the method used here: http://forum.xda-developers.com/showthread.php?t=1198303
If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.
I unpacked a rom with a kernelblob in the root directory, and edited init.rc. Which command should I use to repackage it? If I follow the guide (instead of boot.img I used kernelblob, no extension) I get the EEE Pad logo then scrambled, colored lines all over.
If I, however, install the base rom, then the one where I changed something in the kernelblob, it boots up.
theMIROn said:
If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.
Click to expand...
Click to collapse
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
EDIT: tried to compile myself but got the same issue. I think is related with the need to change source code to make this run on windows.
Working boottools for windows available here: http://forum.xda-developers.com/showpost.php?p=17237701&postcount=443
brk said:
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
Click to expand...
Click to collapse
yep, it's code issue
attached BootTools-Win32.zip with fixed mkbootimg.exe
is there this guide for tf201?
BR
Maframan
maframan said:
is there this guide for tf201?
BR
Maframan
Click to expand...
Click to collapse
You should probably check the TF201 forum.
Could this method be used to pack a new Splash Screen? (I want to change that annoying ASUS logo to something better) Would I go about the Flash_Image method to flash the image after compiled? (I do Not have NvFlash, but I am rooted with Cwm)
Which blobs would I modify as well, just the EBT?
rebound821 said:
NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF
Click to expand...
Click to collapse
Hi Sir,
First of all thankyou for you guide because I did follow you guide and created the insecure boot.image succesfully. I still have one problem, after flashing the boot.image, I still could not root the android device. Why is that? Do I need to change something else in the boot.img?
I havent yet found a simple guide for compiling kernels. Some of them assume too much, and some are just outdated. So I thought I'd write my own for devs/budding devs. Here you go!
Note:
This is not a guide for newbies. It's a dev guide for devs.
Research before asking questions, please
For The Menu driven interactive kernel build script, see Post #31
I will be developing this guide as I go, so it will be incomplete initially, or lacking in detailed explanations.
Essentials:
Ubuntu Box (By this I mean a PC with a Ubuntu installation, not a live CD)
A toolchain-Either the Android NDK, or your own toolchain
HTC Desire GB/Froyo source from htcdevs.com, or sources from github
Familiarity with the linux shell and basic linux commands.
The will to learn
First things first,
1. Getting the sources
The HTC Desire source is available from two kinds of resources-you can either get it from htcdevs.com (official HTC Dev site), or from source code uploaded from someone else. For the purpose of this tutorial, I'll assume we're working on the official HTC GB source code. So download bravo_2.6.35_gb-mr.tar.gz from htcdevs.com.
2. Setting up the compilation box and preparing source code
2.1 Install some essential linux packages from the Linux terminal:
Code:
sudo apt-get install libncurses5-dev
2.2 Extract the source code
The file you downloaded is a tar archive (like a zip file), so you need to extract it to a convenient location. Let's hit the linux shell-open a terminal window in linux (Accessories->Terminal)
Type:
Let's go to our home directory:
Code:
cd ~/
Now, create the directories for our kernel compilation box.
Code:
mkdir -p ~/android/kernel
Now you need to copy the tar.gz file from wherever you downloaded it to, to this dir.
Extract the archive:
Code:
tar -xvf ~/android/kernel/bravo_2.6.35_gb-mr.tar.gz
cd ~/android/kernel/bravo_2.6.35_gb-mr
Now we can view the extracted files within the directory ~/android/kernel/bravo_2.6.35_gb-mr/
2.3 Set up the toolchain
A toolchain is a set of programs which allow you to compile source code (any source code, not just kernels). The toolchain is specific for the processor and hardware, so we need a toolchain specific for Android and especially the Desire. If you're a semiadvanced-pro user, you may consider compiling your own toolchain (See theGanymedes' guide for doing so). If compilation of kernels is all that you require, fortunately for you, there is an easy way-the Android NDK - v7 (latest as of now) is available here
Get the NDK for Linux - android-ndk-r7-linux-x86.tar.bz2
Code:
mkdir -p ~/android/ndk
Now copy the NDK file to ~/android/ndk
Whenever I say copy, you have to manually copy the file with any file manager. Nautilus comes with Ubuntu, and Dolphin with Kubuntu. You may also use the shell of course with
Code:
cp [sourcefile] [destination]
Extract it:
Code:
tar -jvxf android-ndk-r7-linux-x86.tar.bz2
Now add the path for your toolchain to the env variable:
Code:
gedit ~/.bashrc
At the end of the file, add this line:
Code:
PATH=$PATH:~/android/ndk/android-ndk-r7-linux-x86/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin
3. Setting up kernel parameters
Kernels are compiled with a program called gnu make, and use a set of configuration options specified within a file called Makefile.
A vital point to note is that kernels are compiled with a program called gcc (basically the gnu C compiler), and our NDK itself has its own optimized version of gcc. While compiling, we're actually cross compiling it (meaning compiling a binary package on a system which is different from the actual system which is meant to run it- you're compiling it on your PC while it's actually meant to run on your Desire)
This means that when you compile it, you have to make sure that you compile it with the NDK's version of gcc instead of the system version. Otherwise you end up with a kernel meant to run on your pc, duh! Specifying which gcc to use is by the CROSS_COMPILE variable. You can set it up with this command:
Code:
CROSS_COMPILE=arm-linux-androideabi-
Note the hyphen (-) at the end, and do not forget to include it! At compilation time, system will actually use this variable to find all the programs it needs. Eg: The path for gcc will become arm-linux-androideabi-gcc
We can compile kernels with many different options, like with ext4 support, or without; ext4 support as part of the kernel zImage (in which case it makes the kernel larger), or as a loadable module (of the form somename.ko, which is loaded at init.d/init.rc with the command insmod modulename.ko)
We specify the exact options we require with the help of a useful configuration program called menuconfig (which as the name suggests, is a menu for configuration of make options).
An important thing to note is that as far as kernel compilation is concerned, there are a vast amount of options to setup, and unless you're thorough with kernel compilation, you wont be able to set up the options correctly and get your kernel to boot. Fortunately for us, the kernel source already comes with a default set of parameters which can be easily set up.
Note that all make commands must be executed within the directory bravo_2.6.35_gb-mr. Let's go there now:
Code:
cd ~/android/kernel/bravo_2.6.35_gb-mr
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- bravo_defconfig
This produces a .config file (used by the menuconfig) containing essential parameters to produce a booting kernel for the Desire.
Note: There is a simpler way to get the basic .config file, and this is to get it from a running kernel built by someone else. You can extract the .config from a running kernel with these commands:
Code:
cd ~/android/kernel/bravo_2.6.35_gb-mr
adb pull /proc/config.gz
zcat config.gz > .config
Now we can open menuconfig and add anything we need in addition.
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- menuconfig
You can view the huge amount of options available in menuconfig.
You can add ext4 support for example (See image above)
Once you're done choosing options, you can exit menuconfig.
4. Compiling it
This is simple. The basic command is:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi- -j10
The -j10 specifies the number of jobs to execute per operation. I can usually go upto 50 on my Quad core CPU. Beware, this can bring a slow CPU to a crawl and freeze up linux itself.
During compilation, you will see all sorts of messages, which may include warnings too. In most cases, its safe to ignore warnings. If there are errors, the compilation will stop, and you will have to fix the issues.
5. Distributing your kernel to users
At the end of compilation, it generates files named zImage, and various .ko files.
You have to copy them from their default location to a zip file. The best way is to use my variant of koush's Anykernel, and copy the files to it. Then, you can zip the whole folder and lo and behold-you have your flashable kernel zip which you can distribute to others.
You can also remove the zImage and the modules from /system/lib/modules of any kernel zip available with you, and copy over your files to it, at the correct location.
So, let's say that you have extracted an existing kernel zip to the location ~/flashable
The file structure should be like this:
Code:
|-- kernel
| |-- dump_image
| |-- mkbootimg
| |-- mkbootimg.sh
| |-- unpackbootimg
| `-- zImage
|-- META-INF
| |-- CERT.RSA
| |-- CERT.SF
| |-- com
| | `-- google
| | `-- android
| | |-- update-binary
| | `-- updater-script
| `-- MANIFEST.MF
`-- system
`-- lib
`-- modules
`-- bcm4329.ko
8 directories, 11 files
I've included my flashable zip directory along with this post. Download file kernel_flashable.tar.bz2.zip to ~/
Code:
cd ~/
tar -jvxf kernel_flashable.tar.bz2.zip
This will create the directory structure outlined above.
Now after every compilation of the kernel, execute these commands from where you executed make:
Code:
cp arch/arm/boot/zImage ~/kernel_flashable
find . -name '*ko' -exec cp '{}' ~/kernel_flashable/system/lib/modules/ \;
cd ~/kernel_flashable
zip -r mykernel ./
This will create mykernel.zip at ~/kernel_flashable. You can distribute this to your users to flash. Make sure you edit updater-script before though
Common errors and other stuff
Ok, post #1 was simple stuff. Now, supposing you get errors while compiling. Post #2 is about that, and ups the level of knowledge a bit..
Some kernel compilation errors:
Treat warnings as errors-Solved by removing the string "-Werror" from all Makefiles of the file which failed to compile. Some people had said that the real error (Array out of bounds warning) was because of gcc optimizations. But putting -O2 to -O0 didnt do a thing.
No of jobs - ought not to exceed 50.
"warning: variable set but not used [-Wunused-but-set-variable]"-Look at KBUILD_CFLAGS in the main Makefile. Add -Wno-error=unused-but-set-variable to the existing set of flags.
Note the following from gcc manual:
-WerrorMake all warnings into hard errors. Source code which triggers warnings will be rejected.
-w Inhibit all warning messages. If you're familiar with C code and like to fix stuff, rather than ignoring potential bugs, use this only as a last resort- A 'brahmastram' (most powerful weapon in your time of gravest need) as the epics would say
-WerrorMake all warnings into errors.
-Werror=Make the specified warning into an error. The specifier for a warning is appended, for example -Werror=switch turns the warnings controlled by -Wswitch into errors. This switch takes a negative form, to be used to negate -Werror for specific warnings, for example -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect. You can use the -fdiagnostics-show-option option to have each controllable warning amended with the option which controls it, to determine what to use with this option.
So what I did to suppress errors was to add:
Code:
KBUILD_CFLAGS += -w
KBUILD_CFLAGS += -Wno-error=unused-but-set-variable
Though the -Wunused-but-set-variable is not a real issue in itself, it generates so much "noise" that you may miss actual make errors.
This is the error what I was talking about..
Code:
drivers/net/wireless/bcm4329_204/wl_iw.c: In function 'wl_iw_set_pmksa':
drivers/net/wireless/bcm4329_204/wl_iw.c:5075:5: error: array subscript is above array bounds [-Werror=array-bounds]
drivers/net/wireless/bcm4329_204/wl_iw.c:5078:5: error: array subscript is above array bounds [-Werror=array-bounds]
Solution:
Edit drivers/net/wireless/bcm4329_204/Makefile
Locate -Werror within DHDCFLAGS, and delete it.
Code:
DHDCFLAGS = -DLINUX -DBCMDRIVER -DBCMDONGLEHOST -DDHDTHREAD -DBCMWPA2 \
-DUNRELEASEDCHIP -Dlinux -DDHD_SDALIGN=64 -DMAX_HDR_READ=64 \
-DDHD_FIRSTREAD=64 -DDHD_GPL -DDHD_SCHED -DBDC -DTOE -DDHD_BCMEVENTS \
-DSHOW_EVENTS -DBCMSDIO -DDHD_GPL -DBCMLXSDMMC -DBCMPLATFORM_BUS \
-Wall -Wstrict-prototypes -Werror -DOOB_INTR_ONLY -DCUSTOMER_HW2 \
-DDHD_USE_STATIC_BUF -DMMC_SDIO_ABORT -DWLAN_PFN -DWLAN_PROTECT \
-DBCMWAPI_WPI \
This will prevent gcc from treating mere warnings as errors.
How to modify kernels by applying mods - Applying Kernel Patches
Ok, you have compiled a simple stock kernel. Now what? Would you like to add fixes/mods developed by other kernel devs? This post explains patches and how exactly to do this.
Patches to the kernel are applied via patch files. Patch files are simple text files generated by the linux diff program which takes two text files, compares them and writes the differences (hence called diff) to another text file which by convention has the extension .patch
Attached to this post is a patch containing my "Extended battery" fix with Sibere's battfix. I'll explain patching with this. Let's understand the patch file. Open it up in any text editor.
Code:
diff -rupN -X /home/droidzone/android/kernel/exclude.opts bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c
--- bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c 2011-08-25 13:16:53.000000000 +0530
+++ bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c 2011-11-06 16:43:21.544317342 +0530
@@ -118,8 +118,11 @@ PS. 0 or other battery ID use the same p
/* Battery ID = 1: HT-E/Formosa 1400mAh */
#define BATT_ID_A 1
#define BATT_FULL_MAH_A 1400
-
#define BATT_FULL_MAH_DEFAULT 1500
+#define BATT_FULL_MAH_CAMERONSINO 2400
+#define BATT_ID_CAMERONSINO
+#define BATT_TYPE 0
+
Note the first line:
Code:
diff -rupN -X /home/droidzone/android/kernel/exclude.opts bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c
diff -rupN basically describes the command that was used to generate this patch. The -u means that the patch file is something called a universal patch
bravo_2.6.35_gb-mr/drivers/power/ds2784_battery.c was the original file, and bravo_2.6.35_gb-mr.main//drivers/power/ds2784_battery.c was the target file or file which contains the mod..
How to apply patch files?
The command depends on where your current directory is. If you're in ~/android/kernel/bravo_2.6.35_gb-mr/ and your current directory contains the directory 'drivers', you can apply this patch with this command:
Code:
patch -p1<extended_battfix.patch
If you're within drivers, then you have to modify the command like this:
Code:
patch -p2<extended_battfix.patch
Hope you get the gist. Basically, as you move into the source tree, you have to increment the patch level by the number of directories you've moved down into. Very simple, isnt it?
Sharing and Collaborating - Using Github and Commits
Kernel compilation is a group effort (at least it ought to be). When different devs work on different parts of the code and create their own mods, development progresses. For this purpose, it is important that you share your code with other devs. The best way to do this to upload your sources to github.
First, create a github account.
Next you can view other devs' github sources and examine their commits. Commits are basically patches applies to the previous source uploaded. Github commits use the universal patch format and can be viewed directly, downloaded as patch files, and applied to your code. You can also choose to download the whole source tree uploaded by another dev and examine it.
Kernel Build Interactive Menu system
This saves quite a lot of time if you make kernels a lot..
See post #22
Ok, the basic guide is done, guys... If you have doubts, I'll try to clear them
yeah....yeah....yeah...so nice...big thx...will try this as soon as possible..
that is what i searchd so long
edit: rated with 5 stars
with kind regards
Thank you very much droidzone.
I was waiting for a n00b guide.
Tapatalking
good job droidzone
[+1] [ i like]
Added a Howto on how to apply kernel source patch files, to post #3
lol now i understand how patching works.. i write all this **** by myself.. lol
Midian666 said:
lol now i understand how patching works.. i write all this **** by myself.. lol
Click to expand...
Click to collapse
Ha ha.. that would not have been so easy
Droidzone said:
Added a Howto on how to apply kernel source patch files, to post #3
Click to expand...
Click to collapse
sorry for offtopic but nice again and you see many people thought like me with the how to..
with kind regards...Alex
Alex-V said:
sorry for offtopic but nice again and you see many people thought like me with the how to..
with kind regards...Alex
Click to expand...
Click to collapse
I like explaining stuff and sharing..
This guide was written specifically because of your request, and I have never forgotten how you helped when I was a newbie to development.. I wouldnt probably have started developing if not for good responses from Firerat and you.
Droidzone said:
I like explaining stuff and sharing..
This guide was written specifically because of your request, and I have never forgotten how you helped when I was a newbie to development.. I wouldnt probably have started developing if not for good responses from Firerat and you.
Click to expand...
Click to collapse
and now i learn from you lol thx
with kind regards..Alex
Fantastic guide!!!!!!!
Did some more work on the first post. It now includes a flashable zip template and instructions on how to easily create your own flashable zip after compilation is over.
maybe some improvments to your making a flashable zip.
i did this with my kernels.. it took the version infos from the config files.. and put it into a folder... after this u can make zip.
ive stolen this from manus source
Code:
localVersion=`cat .your-config | fgrep CONFIG_LOCALVERSION= | cut -f 2 -d= | sed s/\"//g`
linuxVersion=`cat .your-config | fgrep "Linux kernel version:" | cut -d: -f 2 | cut -c2-`
VERSION=$linuxVersion$localVersion
echo "Kernel version=$VERSION"
rm -rf flash/system/lib/modules/*
mkdir flash/system/lib/modules/$VERSION
mkdir flash/system/lib/modules/$VERSION/kernel
tar czf modules.tgz `find . -name '*.ko'`
cd flash/system/lib/modules/$VERSION/kernel
tar xzf ../../../../../../modules.tgz
cd - > /dev/null
rm modules.tgz
This is good..Actually when I generate kernels I test too many versions that I dont usually change the local version number in the menuconfig. Instead I use the date and time (including second) to name the kernel dir and kernel zip name...
Like this..
Code:
date_str=`date '+%d%m%y_%H%M%S'`
dirname="kernel_"$nameflag"_"$date_str
pckdir="$packagedir/$dirname"
mkdir $pckdir
lastfolder=$pckdir
cd $outdir/
echo
zipnoname="kbase_"$nameflag"_"$date_str
zipaddnoname="kmods_"$nameflag"_"$date_str
zipname=$zipnoname".zip"
zipaddname=$zipaddnoname".zip"
zip -r $zipnoname ./
mv $zipname $pckdir/
As you can see, its part of my script which does a lot of things..
But getting the localversion too is a good thing..I'd put it into a textfile in the zip which users can read..
Great guide. Thanks a lot
Sent from my HTC Desire using Tapatalk
After wandering around looking for an android build of the file command, I finally went ahead and compiled it myself.
The attached package contains the file binary (v5.11), the libmagic.so shared library, the associated magic files and the build specific files that I needed (over and above the source) to build it. The paths of the files are relative to '/'.
Refs:
source: file website (www_darwinsys_com/file/)
compiling: Native Vim on Android (gdr_geekhood_net/gdrwpl/vim-android.php)
Note: Add the location of libmagic.so to LD_LIBRARY_PATH to get rid of the "CANNOT LINK EXECUTABLE" error. (I use /data/local/lib)
Compiled a dynamically linked library and associated binary instead of the monolithic binary built earlier.
samveen said:
After wandering around looking for an android build of the file command, I finally went ahead and compiled it myself.
The attached package contains the file binary (v5.11), the libmagic.so shared library, the associated magic files and the build specific files that I needed (over and above the source) to build it. The paths of the files are relative to '/'.
Refs:
source: file website (www_darwinsys_com/file/)
compiling: Native Vim on Android (gdr_geekhood_net/gdrwpl/vim-android.php)
Note: Add the location of libmagic.so to LD_LIBRARY_PATH to get rid of the "CANNOT LINK EXECUTABLE" error. (I use /data/local/lib)
Click to expand...
Click to collapse
I followed your instructions and it works perfectly.
Code:
$ echo $LD_LIBRARY_PATH
/data/local/lib:/data/local/lib:/data/local/lib:/system/lib:/vendor/lib
$ file
Usage: file [-bchikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type]
[-e testname] [-F separator] [-f namefile] [-m magicfiles] file ...
file -C [-m magicfiles]
file [--help]
$ getprop | grep device
[ro.cm.device]: [jordan]
[ro.product.device]: [umts_jordan]
I have been looking for this for a while. Man!! This post needs some serious attention. Great work.
Sent from my MB525 usiIng XDA
@samveen Any chance you could compile it with libmagic statically linked again to make it portable? Thanks for your time.
osm0sis said:
@samveen Any chance you could compile it with libmagic statically linked again to make it portable? Thanks for your time.
Click to expand...
Click to collapse
@osm0sis Sure. I'll add in a statically linked binary, but it'll take a little time (2-3 days).
samveen said:
@osm0sis Sure. I'll add in a statically linked binary, but it'll take a little time (2-3 days).
Click to expand...
Click to collapse
I was just looking for this. Great tool.
Thanks for your work.
samveen said:
@osm0sis Sure. I'll add in a statically linked binary, but it'll take a little time (2-3 days).
Click to expand...
Click to collapse
Any luck? I think it only needs libmagic statically linked to be portable; the other NDK/Bionic stuff can probably stay dynamic to keep the filesize down. I see file 5.17 source is available now too if you wanted to update your builds to the latest.
osm0sis said:
Any luck? I think it only needs libmagic statically linked to be portable; the other NDK/Bionic stuff can probably stay dynamic to keep the filesize down. I see file 5.17 source is available now too if you wanted to update your builds to the latest.
Click to expand...
Click to collapse
If you want only the system file type, the workaround i use is this (eval $(/sbin/blkid /dev/block/mmcblk0p11 | /sbin/awk ' { print $3 } '); /sbin/busybox echo $TYPE)
In a script just add a var like this
TYPE=$(eval $(/sbin/blkid /dev/block/mmcblk0p11 | /sbin/awk ' { print $3 } '); /sbin/busybox echo $TYPE) and you will have the FS type in $TYPE.
Phone: Samsung Galaxy SII - GT-I9100
Kernel: Dorimanx kernel v10.43v99-mv3
1st ROM : SlimSaber 4.4.2 Maliv3 by fusionjack build of 20140320 (Online)
2nd ROM :
MODEM: UHMS1
MODS: Partition Fix, Hue Blue v4.4 by Kroz :good:
Computoncio said:
If you want only the system file type, the workaround i use is this (eval $(/sbin/blkid /dev/block/mmcblk0p11 | /sbin/awk ' { print $3 } '); /sbin/busybox echo $TYPE)
In a script just add a var like this
TYPE=$(eval $(/sbin/blkid /dev/block/mmcblk0p11 | /sbin/awk ' { print $3 } '); /sbin/busybox echo $TYPE) and you will have the FS type in $TYPE.
Click to expand...
Click to collapse
Interesting but nope; I need file to determine a filetype. Compressed archives via a script, to be specific.
@osm0sis I got the code compiled (both with a dynamic libmagic.so, and libmagic compiled into file) but I need a little more time to compile the magic data (it requires running file on the target device to compile the magic data into a binary datafile). Once I have that figured out (either by compiling it or by creating a script to allow the users to do it themselves, I'll post it all in one go (need one more day).
samveen said:
@osm0sis I got the code compiled (both with a dynamic libmagic.so, and libmagic compiled into file) but I need a little more time to compile the magic data (it requires running file on the target device to compile the magic data into a binary datafile). Once I have that figured out (either by compiling it or by creating a script to allow the users to do it themselves, I'll post it all in one go (need one more day).
Click to expand...
Click to collapse
Awesome! Thanks so much. The magic file isn't terribly important since you can grab one a lot of places and specify it with the -m parameter; keeps the file size down too if you were thinking of including it in the binary somehow!
Alright. I just wanted to thank you again for your work but I managed to make a static native compile (~440kb) of file-5.17 using my N7 and a kbox build environment I set up. It's available in my ARM Android Image Kitchen linked in my sig. Cheers!
osm0sis said:
Alright. I just wanted to thank you again for your work but I managed to make a static native compile (~440kb) of file-5.17 using my N7 and a kbox build environment I set up. It's available in my ARM Android Image Kitchen linked in my sig. Cheers!
Click to expand...
Click to collapse
@osm0sis - Can you please share how did you static compile this? I have setup the Ubuntu 13.10 image on Android using Complete Linux Installer (with all the necessary build tools setup).
I am able to compile this, but it's linking the shared library "libmagic.la".
Need to pass --static to ./configure and have a cross compiler set up, for ARMv7.
ericlnu said:
Need to pass --static to ./configure and have a cross compiler set up, for ARMv7.
Click to expand...
Click to collapse
I don't think that's a valid option.
Code:
$ ./configure --static
configure: error: unrecognized option: `--static'
Try `./configure --help' for more information
amit.bagaria said:
I don't think that's a valid option.
Code:
$ ./configure --static
configure: error: unrecognized option: `--static'
Try `./configure --help' for more information
Click to expand...
Click to collapse
Nope, seems not ^_^. Sorry, it usually is with autoconf derived configure scripts.
amit.bagaria said:
@osm0sis - Can you please share how did you static compile this? I have setup the Ubuntu 13.10 image on Android using Complete Linux Installer (with all the necessary build tools setup).
I am able to compile this, but it's linking the shared library "libmagic.la".
Click to expand...
Click to collapse
Haven't tried it using a full Linux image on Android, just made it native compile in KBox2 on my N7'13 for awhile by editing in the gettext functions it was complaining about, and have since moved on to cross-compiling on my Windows 7 desktop in Cygwin using the NDK. There were still a few tricks to getting it to be a true static compile. It's all linked in my post here:
http://forum.xda-developers.com/showthread.php?p=54510825
My latest compile included in my AIK-mobile package is file 5.20. :good:
I don't suppose you could do a quick compile with the -fPIE flag? Trying to use this on 5.0 + and don't want to patch my linker.
Tried to compile it myself (it sort-of worked, file --version is operational) but when I try to actually use it for something my terminal borks out and switches to some weird font after about 20 warnings. (configure also seems to be using the -rpath flag apparently, linker complains about it) hmm
EDIT: I've got it working after some trial and error. If anyone requests I'll post it
EDIT 2: android 6.0's linker seems less forgiving than 5.0/5.1, need to compile without -rpath (so no just using ./configure) will keep posted
Can you please post the file binary you built with -pie ?
Hi Folks
Here's a native Bonic GNU GCC ( 4.6.0 ) + BinUtils ( 2.22 ) compiled for armv7-a with c and c++ support!
Testing:
I used an HTC Sensation running CM9 for testing
[EDIT:] Using JB 4.2.1 on a Nexus 7 causes a segmentation fault when trying to compile...... Investigation Continues!
Installing:
Download and unpack this archive [ bionic_gcc_binutils.7z ]
copy the directories to the /system directory ,
adb push whilst in the directory you extracted the download to should do the trick
adb push . /system
Test the gcc
Code:
adb shell gcc /system/usr/src/hello.c -o /system/bin/hello
adb shell hello
HELLO OUTPUT: Hello Bionic
Check the Dynamic Linker
Code:
adb shell readelf -l /system/bin/hello | grep 'linker'
OUTPUT: [Requesting program interpreter: /system/bin/linker]
The GNU linker - ld
ld currently only has one search path by default, that is /system/lib, you must manually set links to other location ( i.e /vendor/lib )
Getting Help - RTFM ( Read The F***king Manual )
No seriously the man and info pages can be found in the share directory in the archive
Personal Thoughts
Although GCC is a very mature project, I'd still consider this as PRE-ALPHA R&D as I'm certainly not an expert when it comes to toolchains etc. I basically used a bruteforce attack to build this. which involves compile - test - tweak/fix - rinse - repeat and stop when it looks about right So I could have quite easily misconfigured a compiler flag or patch a file in an inappropriate manner which may manifest itself further down the line.
I suppose the acid test would be to try and compile the linux kernel using this toolchain.
I had a search around to see if this had already been covered, It looks like the C4Droid project has it covered, at a cost!! but I do see the question on native compilation come up every now and again so hopefully this should help some folks out at least.
I'm curious, although this is old by now, what CFLAGS (and other environment variable settings) and configure options did you use in order to get that to compile? I've messed around with gcc 4.9.1 and binutils 2.24 using the android toolchain from NDK version r9d, and haven't had any luck.
jdmanley87 said:
I'm curious, although this is old by now, what CFLAGS (and other environment variable settings) and configure options did you use in order to get that to compile? I've messed around with gcc 4.9.1 and binutils 2.24 using the android toolchain from NDK version r9d, and haven't had any luck.
Click to expand...
Click to collapse
Are you still curious about this? I did this just recently and it took quite a while to find the right configurations and flags.
I'd be happy to post the output of 'gcc -v' or show what config parameters I used
Surge1223 said:
Are you still curious about this? I did this just recently and it took quite a while to find the right configurations and flags.
I'd be happy to post the output of 'gcc -v' or show what config parameters I used
Click to expand...
Click to collapse
please share