How to compile native android code - Droid Eris General

Hi everyone,
There has been a few questions on how to compile native android code (for exploits and such). Easy enough.
Go to http://source.android.com/download. You will need to be running Linux. Ubuntu is easiest. Follow the directions to get the source code for android downloaded and compiled.
Run this command
export PATH=/path/to/android/source/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin
Run arm-aebi-gcc or arm-aebi-g++ (depending on the language, c or c++) followed by
-o (OUTPUT) (INPUT)
So, for example, test.c would be:
arm-aebi-gcc -o test test.c
And test.cpp would be
arm-aebi-g++ -o test test.cpp
Just a note, this will make STATICALLY linked files. Meaning any headers will be included INSIDE the executable. Simply put, this means the files will be HUGE for large projects. There is a program, named agcc, which fixes this and can be found here:
http://plausible.org/andy/agcc
Put it in /bin by:
Code:
cd /bin
sudo wget http://plausible.org/andy/agcc
chmod 755 agcc
chmod +x agcc
Run agcc -o (OUTFILE) (INPUT) to compile. Be warned though, if a header is in the file that isn't in bionic (android's smaller libc) it won't compile.
Hope this helps!

+1
Awesome

............(stuipid mistake >>was<< here)..............

Thanks man...

now i can break out my bootable 50 meg linux disc and play around.
love that thing used to use it to crack windows passwords
should see the guys face when you crack his 20 char password in 5 mins without ever needing to use it.
well not really cracking but changing it. used to work at the pentagon. this one guys who used to be support for one dept. thought it would be funny to change all the admin passwords in his office. so when one of the pc's was beyond his repair. i showed up and he was like give me 10 min and i'll log you in. well 5 mins later i was fixing the machine while he was screwing off. boy was he pissed.
how big's gcc? cause i'll need to compile it for my linux.

rigamrts said:
how big's gcc? cause i'll need to compile it for my linux.
Click to expand...
Click to collapse
Massive. You're definitely better off using the prebuilt toolchain found in the Android (N|S)DK.

I would like to add something to this.
libc is essentially derived from the kernel. So, if you take agcc, and make changes to use the libc directory (I don't remember it atm) and NOT bionic, the app won't compile. Simple enough, libc is based of the kernel, so bionic is based of the android kernel. Things missing in bionic that are in libc WON"T work simply because certain kernel calls in glibc DON'T exist on the Android platform.
My exploit relied on the fact that I would be able to compile exploits using glibc, instead of using bionic. So it failed. Thats what I've figured out so far anyways.

zifnab06 said:
My exploit relied on the fact that I would be able to compile exploits using glibc, instead of using bionic. So it failed. Thats what I've figured out so far anyways.
Click to expand...
Click to collapse
Would you be willing to share the code for that exploit, even if it doesn't work? (sorry if you already have, I didn't see it anywhere)
I may be able to help.

Look up anything in our old thread, especially when we were talking about "sys/personality.h". The one I was working with exploited a hole that was patched (min_map_addr).

This blog post
honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-for.html
(Sorry, my account isn't allowed to post links yet.)
gives a minimalist approach to using dynamically linked executables. (In particular, see steps #2 and #3 for the sources for hello.c and start.c) I gave it a try, and it seemed to work without agcc, e.g. with a makefile like the following (and with the arm-eabi- executables in the PATH of the user invoking the make) :
Code:
AR = arm-eabi-ar
AS = arm-eabi-as
CC = arm-eabi-gcc
CXX = arm-eabi-c++
LD = arm-eabi-ld
NDK_KIT = /opt/android/android-ndk-1.5_r1
PLATF_KIT = build/platforms/android-1.5
ARM_INC = $(NDK_KIT)/$(PLATF_KIT)/arch-arm/usr/include
ARM_LIB = $(NDK_KIT)/$(PLATF_KIT)/arch-arm/usr/lib
PLATF_INC = $(NDK_KIT)/$(PLATF_KIT)/common/include
OBJS = hello.o start.o
EXES = hello
hello: hello.o start.o
$(LD) \
--entry=_start \
--dynamic-linker /system/bin/linker -nostdlib \
-rpath /system/lib -rpath $(ARM_LIB) \
-L $(ARM_LIB) -lc -o hello hello.o start.o
hello.o: hello.c
$(CC) -I $(ARM_INC) -I $(PLATF_INC) -c hello.c
start.o: start.c
$(CC) -I $(ARM_INC) -I $(PLATF_INC) -c start.c
clean:
rm -f $(OBJS) $(EXES)
HTH
bftb0

Just curious, but I'm trying to get some native code that I've compiled to run on the Incredible. I've followed the instructions to download the the arm gcc, compiled my C code, and adb push'ed the executable over to /sdcard but I get a "permission denied" error when I try running it from my phone and adb shell. Does the phone have to be rooted in order to run native C compiled executables?
Thanks!

zebdor44 said:
Just curious, but I'm trying to get some native code that I've compiled to run on the Incredible. I've followed the instructions to download the the arm gcc, compiled my C code, and adb push'ed the executable over to /sdcard but I get a "permission denied" error when I try running it from my phone and adb shell. Does the phone have to be rooted in order to run native C compiled executables?
Thanks!
Click to expand...
Click to collapse
On an unrooted phone, push your code to /system/local or another place that you can write to and chmod it to be executable. By default the sdcard is mounted no execute. You will either need to add the directory you put it in to the path or execute it implicitly by specifying it is in the local directory.
for example ./myprogram
I hope that helps. I re-read it and it doesn't make much sense unless you have a firm grasp of the things that happen between the lines.
best of luck.

Thanks. Good stuff.

rigamrts said:
now i can break out my bootable 50 meg linux disc and play around.
love that thing used to use it to crack windows passwords
should see the guys face when you crack his 20 char password in 5 mins without ever needing to use it.
well not really cracking but changing it. used to work at the pentagon. this one guys who used to be support for one dept. thought it would be funny to change all the admin passwords in his office. so when one of the pc's was beyond his repair. i showed up and he was like give me 10 min and i'll log you in. well 5 mins later i was fixing the machine while he was screwing off. boy was he pissed.
how big's gcc? cause i'll need to compile it for my linux.
Click to expand...
Click to collapse
This is one of the most unbelievable stories ive read in a while. The fact that the pentagon had an administration department without policies or security in place to prevent such a widely known method, is comical.
btw, such a linux cd is no secret. Its called pnordahl.

Useful information

I'm surprised to see that many of you don't use the Forum's search function and simply start new topics over and over again. What funny is that the info you put here is old and useless.
I've posted an article on how to compile native C code for Android months ago, with several examples and tools:
http://forum.xda-developers.com/showthread.php?t=514803
or direct link herE:
http://www.pocketmagic.net/?p=682
However this technique is now too old.
The best approach is to simply use the NDK and build a custom Makefile for Cygwin's make under windows or easier under linux, see:
http://betelco.blogspot.com/2010/01/buildingdebugging-android-native-c.html

radhoo said:
I'm surprised to see that many of you don't use the Forum's search function and simply start new topics over and over again. What funny is that the info you put here is old and useless.
I've posted an article on how to compile native C code for Android months ago, with several examples and tools:
http://forum.xda-developers.com/showthread.php?t=514803
or direct link herE:
http://www.pocketmagic.net/?p=682
However this technique is now too old.
The best approach is to simply use the NDK and build a custom Makefile for Cygwin's make under windows or easier under linux, see:
http://betelco.blogspot.com/2010/01/buildingdebugging-android-native-c.html
Click to expand...
Click to collapse
Thank you for your very informative links. I'll take a look tonight, since I find this very interesting and would love to compile a few things for Android.
"What funny is that the info you put here is old and useless." - This was posted almost 10 months ago. That's a long time in smart phone years. By the same token, if it were January 2010 and I was looking for this info, I would assume that a post from May 2009 would be dated too.
"I'm surprised to see that many of you don't use the Forum's search function and simply start new topics over and over again." - Maybe zifnab did search and find your post and deemed your technique too old for Jan. 2010, so he created a new post with newer information. Or maybe he wanted to show a different way to do the same thing. Or maybe he figured that many users only have/take the time to look in their phone-specific forum. No one knows other than zifnab.
Personally, I welcome multiple posts by different people on the same topic. Everyone is different and often have different takes on the same thing. I find it easier to understand many techniques/topics if I get multiple perspectives.
Again, thank you for your contribution.

I need to compile the library with some modifications. how to do it as simple as possible? what will it take?

vlad072 said:
I need to compile the <library> with some modifications. how to do it as simple as possible? what will it take?
Click to expand...
Click to collapse
Did you get any thing in this regard ? Even i want to compile a part for library for the Android 5.1.1 device but not able to find any resource. Help will be appreciated.

Related

Question for experienced devs

OK, let me first preface by saying that I have like zero development experience but I'm pretty smart and I'm trying to learn. You have to start somewhere, right?
So I decided to take a crack at it when I came across this thread:
http://forum.xda-developers.com/showthread.php?p=24278953
It's a Linux tutorial but having only a Mac, I decided to see if I could make it work. It didn't but the point is that, in the process, I learned a LOT.
So following a suggestion, I scrapped the whole Mac idea and started all over on an Ubuntu 11.4 VM. Which works great but it's a little less forgiving than the Mac.
Anyway, I have my build environment completely set up with all the necessary packages installed...no problem. I have the device specific proprietary files in place and pre-builts installed as well.
Now its time to build. I do so using this command:
Code:
source build/envsetup.sh
brunch otter -j$(gprep -c processor /proc/cpuinfo)
...runs for a couple minutes before stopping at this error:
Code:
In file included from frameworks/base/media/libmedia/IMediaPlayerService. cpp:25: frameworks/base/include/media/IOMX.h:29:17: error: jni.h: No such file or directory make: *** [out/target/product/otter/obj/SHARED_LIBRARIES/libmedia_ intermediates/IMediaPlayerService.o] Error 1
So basically, the file "IOMX.h" makes a declaration to include "jni.h" which isn't anywhere in my /android tree.
Upon further research I learn that "jni.h" has something to do with Java. I have the required java-sun-jdk 6.1.x installed so I figured it must be a problem with my $PATH. I found the "jni.h" in question in the Java folder and did an export $PATH to that folder. Then I entered echo $PATH to make sure:
Code:
echo $PATH /home/linux/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/lib/jvm/java-6-sun-1.6.0.26
Sure enough, the folder where "jni.h" is located is included in my path, but I'm still getting the same errors.
What am I doing wrong?
Sent from my Kindle Fire using xda premium

PengDroid: a healthy fusion of Debian and Android

Notice: Now that PengDroid has been rolled into BotBrew, this installation method is now deprecated. You'd get all this, and a package manager GUI, by installing BotBrew "basil".
Click to expand...
Click to collapse
I love Debian, and I think it's nice to have a chroot environment full of useful tools. However, there's always a barrier keeping Android and Linux from talking to each other. This is why BotBrew is designed to not rely on a chroot system.
PengDroid is an experimental chimera of Android and Linux that gives you access to a chrooted Linux userland while preserving access to the Android system.
If this sounds dangerous, let me explain why this is safe. Have a look at the root directory of a Linux system and the root directory of an Android system; notice how they don't overlap much. This means that we could safely map some of the most useful Android directories into the Linux namespace; there's no need to modify the Android side. Let's see the code.
I made a prebuilt archive to demonstrate this method. In exchange for trying, you get a nice Debian chroot. What's not to love?!
download pengdroid.tgz to your Android device
unpack it to /data (or /sd-ext): tar zxvf path/to/pengdroid.tgz -C /data
run it: /data/pengdroid/init
For a quick sanity check, run: getprop ro.product.model (whoa, Android inside Linux)
Then, for some more fun: apt-get
By default, no repositories are enabled.
Note: Before we start installing packages from Debian, we should actually install Debian. Wait, what? Right, PengDroid is so small because it packs just enough for us to use dpkg/apt; but many Debian packages assume that we have a complete setup. To bootstrap a minimal Debian installation, run /debian.sh (which makes the final installed size a whopping 58mb). If that's too much, keep reading.
Advanced Usage
Installing a minimal Debian gives us a fairly complete, but still small, *nix system. If we wanted to go even lighter, but still have a reasonably robust setup, we could run the alternative installer: /debian.sh apt -- which installs a complete dpkg/apt system.
It's a hassle to run /data/pengdroid/init all the time, but we could fix that by making a shortcut:
Code:
busybox mount -o remount,rw /system
echo '/data/pengdroid/init -- "[email protected]"' > /system/bin/pengdroid
chmod 0755 /system/bin/pengdroid
Now, we could just prefix everything with pengdroid, like so: pengdroid python
Or, if we just want a shell: pengdroid
Awesome! Although you can probably do better on the name assignment, this is another great step transforming Android into a real Unix Distribution
Yeah, the name's awkward. But I figured I'd roll this into BotBrew some day, when we slim it down enough. It's already pretty tiny for a Linux distro, but it could be even smaller if all we want is a package manager.
PengDroid is now on a diet. It installs to some 7.7mb, with a 3.5mb download size. This is good enough to support package management, and we're one command away from a minimally-functional Debian setup (instructions in OP).
/edit:
I just fixed a potential privilege escalation vulnerability in init.c, and added some new PATH-handling code. Instead of overriding the PATH, it now prepends to it. In addition, if PATH contains a double-colon ( :: ), it inserts its additions between the colons instead of prepending. To install the new init executable without reinstalling, do (outside of PengDroid):
Code:
wget http://dl.inportb.com/pengdroid.init
cp pengdroid.init /data/pengdroid/init
umount /data/pengdroid
rm pengdroid.init
/edit:
It seems that Debian Squeeze is a bit too old for our needs. Specifically, for reliable package management across many types of Android devices, we need multiarch support. So now, I'm tracking Debian Sid.
Excited to see the debian runit scripts and how they operate. I am too noob to know the difference between the Debian distros, but I have learned to trust you in such decisions.
How about adding the pengdroid symlinks to bbsh when it makes it to +1?
I'm sure it or something like it is already firmly in the testing phase. Sounds like SOP now that I write it. I just always forget and try to get a pengdroid shell between flashes.
Watch, he's gonna tell me an easier way I should know already...
Sweet, Finally, Debian & Android rolled up together in a neat little package. Il test this out later,
& do you hail from West or South London by any Chance, where i come from "Peng" is a slang term for "Sexy"
Oh snap, I lost track of this thread
You might have noticed a pengdroid.zip archive in my files. That's a self-extracting package for those who don't have a working tar utility. You could extract it using unzip, or just run the file like a program:
Code:
chmod 0755 pengdroid.zip
./pengdroid.zip
mateorod said:
Excited to see the debian runit scripts and how they operate. I am too noob to know the difference between the Debian distros, but I have learned to trust you in such decisions.
How about adding the pengdroid symlinks to bbsh when it makes it to +1?
I'm sure it or something like it is already firmly in the testing phase. Sounds like SOP now that I write it. I just always forget and try to get a pengdroid shell between flashes.
Watch, he's gonna tell me an easier way I should know already...
Click to expand...
Click to collapse
We'll essentially be killing the existing sysvinit system and offering additional packages containing runit scripts. sysvinit is pretty good, but not enough to keep track of services.
I'd like to have [almost] perfect compatibility with the current BotBrew. BotBrew works by attaching its own filesystem (which conveniently lives under /botbrew) to the existing Android tree. Pengdroid turns this relationship on its head: it attaches crucial parts of the Android filesystem to the Debian tree, and then chroots into Debian. Technically, the chroot/reversal is not required, but it simplifies cleanup.
In BotBrew+1, /botbrew lives within the Debian filesystem tree already. After chrooting into Debian, we have automatic access to /botbrew as before. But what about direct access without chrooting? That's easy... just selectively attach the debian/botbrew directory the same way we've always been doing. So we'll need a couple of changes:
bbsh needs to detect if it's called from within the chroot and handle that special case
the init program (for starting the chroot) should add /botbrew/bin to the PATH
Multiarch is another fun thing to play with. Debian recently (officially) gained the ability to install libraries for multiple architectures at the same time. For example, this lets you have both i386 and amd64 software installed on your 64-bit system. In BotBrew, we'll take advantage of this to install both Debian packages and Android-native packages.
Why are we still planning to distribute the old stuff (repacked from Opkg) if we could get all of that and more from Debian? Simply put, these Android-native packages tend to be more efficient in terms of execution speed and space usage. But during the testing phase, I'd like to use Debian software primarily because we get those for free
Der_Panzerfaust said:
Sweet, Finally, Debian & Android rolled up together in a neat little package. Il test this out later,
& do you hail from West or South London by any Chance, where i come from "Peng" is a slang term for "Sexy"
Click to expand...
Click to collapse
Just a coincidence, I assure you, since I'm on the other side of the great pond I thought this might be an appropriate name for a penguin cyborg, that's all.
Roger that
Sent from my E15 using xda premium

[HOW-TO] extract kernel from source, compile, and insert on GPE (510)

How to extract the boot image from your tablet, set up adb, compile a new kernel with cool options, and put it back on your device!
UPDATED for Lolipop 12-4-14
This is a complete guide from start to finish, copy and paste style. If you own a gpe510, or any other AOSP device and a computer running Debian Linux, you can do all of this.
If all you want is the modified kernel, download from here:
Sleekai Kernel For The LG GPad 8.3 V510(GPE)
​
I am hoping people will add to this with new ideas and patches in order to make the GPE a better device. I see the potential for all sorts of neat stuff.
This guide assumes a basic knowledge of linux operating systems. I am using a Debian 64 bit (wheezy stable) to compile my kernel. I have used many, many hours of the day to figure this out properly, with specific thanks going to Pete of Pete's Blog for his image tools.
But first, lets keep this simple. As usual, you are on your own if you brick your device, though I don't see how you could if you are paying attention!
There are dependencies for building your own kernel, and you will definitely want to use a 64 bit system as a 32 bit will not work properly for kitkat.
Here are all of the packages you will need, and they will draw in further dependencies when you install, but these are it! So, here we go:
Open a terminal, su to root and:
Code:
dpkg --add-architecture i386
##This will allow for the use of some 32 bit librarys that we will need for both adb and the kernel compile. Then:
Code:
apt-get update ; apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386 libc6-i686:i386 lzop liblzo2-dev libgpm2:i386 git-core git gnupg flex bison gperf libsdl1.2-dev libesd0-dev build-essential zip curl gedit libncurses5-dev zlib1g-dev fakeroot lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib
Next, you will need to install adb and have your permissions set up.
In order to do this you will need to go into the developer options on your device to enable debugging on your tablet. Go to settings/about tablet/build number, and tap on build number several times to unlock the developer options.
then:
You will need to create new udev rules for your device in/etc/udev/rules.d on your computer.
Use "lsusb" in your terminal to find the manufactures code of your device. it will show up as a nexus 4, or Google device.
You will need to create a file in your computer in /etc/udev/rules.d/99-android.rules.
You can use gedit if you like:
Code:
gedit /etc/udev/rules.d/99-android.rules
Put the following inside and save, changing the manufactures code as necessary to fit your device, and change “your-login” to your login name on your computer.
Code:
# Google Nexus devices
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", OWNER="your-login" # Google Nexus devices
18d1 is the manufacturers code.
You will then want to restart udev on your computer:
Code:
service udev restart
you will now have permissions to access your android device from user space.
Now to download adb and get started. You should probably not use adb from the Debian repositories, as it may be an older version. the V510 is using kitkat android and needs the latest build of adb to work properly. It is a good idea to get rid of any old adb files on your computer first. The code below will do just that.
Code:
apt-get purge android-tools-adb android-tools-fastboot
Now download the latest adb bundle from here:
http://developer.android.com/sdk/index.html
Move it into a new directory,
*note -the version number may be different.
Code:
mkdir ~/adb
Code:
cd ~/adb
Code:
unzip adt-bundle-linux-x86_64-20131030.zip
su to root and Move the bundle to /opt:
Code:
mv adt-bundle-linux-x86_64-20131030 /opt/android-sdk-linux-x86_64-20131030
Other google products reside in /opt, this should too. This takes a minute or so on slow machines.
Next we need to link adb to /usr/bin
Code:
ln -s /opt/android-sdk-linux-x86_64-20131030/sdk/platform-tools/adb /usr/bin
Code:
ln -s /opt/android-sdk-linux-x86_64-20131030/sdk/platform-tools/fastboot /usr/bin
We are ready to begin working on the device! first start the adb server and look for your device.
Code:
adb start-server
Code:
adb devices
You will then need to confirm the connection on your tablet screen to allow access from your computer.
Okay, wev'e got this first part set up. it's time to begin working on a kernel!
Lets get started.
I want to extract and build my zimage in $userspace, so open a terminal from /home and:
Code:
mkdir ~/android
Download the source package LG-V510(G-Pad 8.3 Google Play Edition)_Android_KK_V510_11c from here :
https://www.lg.com/global/support/opensource/opensourceList?types=ALL&search=lgv510
and open it to find three folders, including a kernel folder. Move the kernel folder to ~/android and then:
Code:
cd ~/android
Download the current eabi-4.6 Google tool chain to ~/android to cross compile your android kernel:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8
When it completes, enter ~/android/kernel and get ready to compile a new kernel from the source code.
Code:
cd ~/android/kernel
Do the following each time you compile another kernel. This insures the correct path.
Code:
export PATH=$PATH:~/android/arm-eabi-4.8/bin
Code:
arm-eabi-gcc --version
you should get:
Code:
arm-eabi-gcc (GCC) 4.6.x-google 20120106 (prerelease)
Copyright (C) 2011 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.
Continue on! we are not done yet!
Code:
export ARCH=arm
Code:
export SUBARCH=arm
Code:
export CROSS_COMPILE=arm-eabi-
Code:
export KERNEL_DEFCONFIG=palman_defconfig
Code:
make clean
Code:
make palman_defconfig
Doing the above prepares your kernel build environment, while the following code opens a interface to configure the kernel. You can simplify this later however you wish.
But for now,
Code:
make menuconfig
At this point make whatever changes you wish to the config file. for a list of the changes I have made, and that are in the kernel available to download, look in the sleekai kernel thread. (At start of thread, or in my signature).
After saving your changes,
Code:
make
Or conversely
Code:
make -o2
which will optimize the make. I recommend using simply "make" first, as the other may not properly show errors should any occur.
and go make a pot of coffee, and probably drink the whole pot! This will take a while.
At the end you will see that the "zimage is ready"
If you have errors, then you probably have dependency problems. If not, Yay! You compiled your first kernel, but we are not done yet!
The zimage you just produced is stored in /kernel/arch/arm/boot/zImage
To put both the zimage and any modules into a separate folder inside of ~/android so as to make extracting them easier:
Code:
mkdir ~/android/kernel_output
Code:
cp ~/android/kernel/arch/arm/boot/zImage ~/android/kernel_output/zImage
Code:
find ~/android/kernel -name "*.ko" -exec cp {} ~/android/kernel_output/ \;
The above code will find all the modules for your kernel. We don't need them for this tutorial, but it still is mighty handy!
Extract your boot image (boot.emmc.win) for the ramdisk You may also download the stock.zip from the sleekai kernel thread
Now make a backup to transfer to your computer.
Reboot to recovery on your tablet. I'm using TWRP. If you are using something else it should be just as easy.
Code:
adb reboot recovery
Only tick the boot
make a backup to your sd card. I changed the name to boot.bac to keep it simple
reboot
make sure the backup of boot is present using a file explorer. I am using ES File explorer.
On your computer, pull the file using adb
Code:
adb start-server
Code:
adb devices
Code:
adb pull /storage/sdcard1/TWRP/BACKUPS/LG0000606708987/boot.bac /home/sleek
sleek is my user name, replace with yours or use tilde.
What we are after is the "boot.emmc.win" file. We will only need this and the zImage to compile a new boot image and run it on your tablet.
The tools to extract the kernel and ramdisk from the boot.emmc.win you will need the following boot image tools installed on your computer.
So, again, lets keep this simple. All the tools are forked to my github for ease of use.
So lets install the tools! Ready?
As Root:
Code:
mkdir /usr/src/android
Code:
mkdir /usr/src/android/boot
Code:
cd /usr/src/android/
Code:
git clone https://github.com/sleekmason/bootimg-tools.git
Code:
cd bootimg-tools/libmincrypt/
Code:
gcc -c *.c -I../include
Code:
ar rcs libmincrypt.a *.o
Code:
cd ../mkbootimg
Code:
gcc mkbootimg.c -o mkbootimg -I../include ../libmincrypt/libmincrypt.a
Code:
cp mkbootimg /usr/local/bin/
Code:
cd ../cpio
Code:
gcc mkbootfs.c -o mkbootfs -I../include
Code:
cp mkbootfs /usr/local/bin/
Code:
cd /usr/src/android/bootimg-tools/mkbootimg/
Code:
wget https://raw.github.com/sleekmason/bootimg-tools/master/mkbootimg/unmkbootimg.c
Code:
gcc -o unmkbootimg unmkbootimg.c
Code:
cp unmkbootimg /usr/local/bin/
Now everything is in place to make a new boot image for your tablet!
Finishing this up is easy.
As root, we made a directory in /usr/src/android/boot for your boot.emmc.win file to be torn apart:
Code:
cd /usr/src/android/boot
Copy your new zImage and the boot.emmc.win file you extracted from your device.
Note* "/home/sleek" is the path on my computer, and should be changed to reflect yours!
Code:
cp /home/sleek/android/kernel_output/zImage /usr/src/android/boot
Code:
cp /home/sleek/boot.emmc.win /usr/src/android/boot
Now unpack the boot.emmc.win file to get the ram disk
Code:
unmkbootimg -i boot.emmc.win
Now you may remove the current boot.emmc.win file, and the resultant kernel file as we will be making new ones, and rename the zImage file you moved here to "kernel".
Code:
rm boot.emmc.win kernel && mv zImage kernel
Now repack using the command given to you during the unpack:
Code:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80208000 --ramdisk_offset 0x82200000 --second_offset 0x81100000 --tags_offset 0x80200100 --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=palman lpj=67677 vmalloc=300M' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.emmc.win
Note* For 500 users this may be different. Simply use the command from the prompt.
You should now have a brand new boot.emmc.win image in /usr/src/android/boot!!
To push back on your device to test
Code:
adb reboot bootloader
Code:
fastboot boot boot.emmc.win
USING the above will only put your kernel build into memory and should not hurt your device if something goes wrong. Use the command below to make it permanent.
If everything works well, you should see the change you made to the /general/perf-localversion/ in your settings under kernel. from there it's up to you to hack away! make new and unique kernels!
If you want your kernel to survive reboot do;
Code:
fastboot flash boot boot.emmc.win
then:
Code:
fastboot reboot
You can expect a slow bootup on the first go around as your new kernel populates the widgets, etc..
NOTE*For the use of the latest eabi-4.7 google toolchain, you will need the libglibc libraries from the "testing" branch as gcc 4.7 is in testing. I advise completing the guide with eabi 4.6 first before trying 4.7.
The gamma correction though enabled in 4.6, isn't near as good as the native compile using 4.7. If you want the screen to look like it does in my kernels, you will need 4.7
For the eabi-4.7:
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7
That's it! Good luck! Remember, If you post a kernel you have made, you will need to show your kernel source, etc . . . Git hub is a good choice to keep track of changes you make. Best regards, Sleekmason
If you are a v500 user and want to build your own kernel!
First, read the above post as you will be following the steps listed there.​
There are just a couple of changes that you will need to do, and maybe a riddle to figure out as well. Read on.
You will need to download the v500 source from here: https://www.lg.com/global/support/opensource/opensourceList?superOsCategoryId=CAT00000001&osCategoryId=
Look for the LGV500 kernel source.
Where it says "palman" for the defconfig items, you will want to replace that with the defconfig for the 500, so replace palman with awifi-perf,
like this:
Code:
export KERNEL_DEFCONFIG=awifi-perf_defconfig
Code:
make awifi-perf_defconfig
Important
Follow the guide and build with the Google Toolchain eabi4.6 first
LG compiled for the 500 and 510 using the eabi4.6. It works, and will give you a feel for the process, and allow you to use your kernel.
Note*
I use the google toolchain eabi-4.7 for the sleekai kernels as it changes the gamma to reasonable defaults on the 510 without further tweaking. After compiling a kernel or two to get a feel for it, you should try using the 4.7 toolchain. To do so, you will probably need the libglibc libraries from the "testing" branch. Look it up.
caveat: I recieved a compile error for the v500 when I used the eabi-4.7 . . . . . yeah. You'll have to work that out.
There is a modified anykernel script for emmc devices out there (Search Google or here in xda). You will have to use the anykernel script after making your boot.emmc.win image as fastboot won't work on the 500. There may be another way .... But I don't know what it is.
Edit* There are now two different kernels for the LG GPad 8.3 V500(awifi) located in the development section of the forum.
Best of luck! -sleekmason
Can this be used to create a kernel for the non Google Play Edition Gpad to be able to allow us to install the Google Play edition ROM on it
Sent from my SM-N900W8 using Tapatalk
Canadoc said:
Can this be used to create a kernel for the non Google Play Edition Gpad to be able to allow us to install the Google Play edition ROM on it
Sent from my SM-N900W8 using Tapatalk
Click to expand...
Click to collapse
I would think so. I edited the above to show how to put the image back on your device. You should be able to use any source you wish to compile with. My thoughts are that you might wish to examine the differences in the ram disk if any.
sleekmason said:
Howdy, I would like to share how to download the kernel source for the gpe, compile a new custom kernel, and insert into your LG gpad GPE 510.
...
Click to expand...
Click to collapse
Thanks for the guide. Making GPE kernel was my next step in trying to get the GPE ROM to work on v510.
I just made guide for getting your Android build environment going if you want to use it on your blog or where ever.
http://forum.xda-developers.com/showthread.php?t=2629008
The problem with v500 is that it does not have fastboot so we can not flash kernel like how you can on v510.
@ AndroidUser00110001 Hi! I know that somebody tweaked the Any kernel to work on emmc devices... Maybe it could be adapted? Actually getting the menuconfig and make should be the same process as well as repacking the image. I take it just getting it back on the 500 device is the problem?
I will add your link to this post for setting up a build environment if that is okay.
sleekmason said:
@ AndroidUser00110001 Hi! I know that somebody tweaked the Any kernel to work on emmc devices... Maybe it could be adapted? Actually getting the menuconfig and make should be the same process as well as repacking the image. I take it just getting it back on the 500 device is the problem?
I will add your link to this post for setting up a build environment if that is okay.
Click to expand...
Click to collapse
Is that the koush any kernel? I was going to mess with that too. I just need a small break now. Took a few days to get new system exactly how I want it.
Go ahead and use guide...mo problem at all.
AndroidUser00110001 said:
Is that the koush any kernel? I was going to mess with that too. I just need a small break now. Took a few days to get new system exactly how I want it.
Go ahead and use guide...mo problem at all.
Click to expand...
Click to collapse
Yes, from here: http://forum.xda-developers.com/showthread.php?t=847265
I noted that boot was on block nncblk0p21 on our device, and not 22? better double check that. I tried it Anykernel as well to no avail when getting this set up. Fastboot is Awesome!
It's taxing to get it set up right. Seems like things change very often for the dependencies based on other package changes. I ussually go with testing but redid two partitions with stable. The 32 bit is just going to sit there, which seems kinda silly due to the need for extra packages in 64 to compile for 32 but whatever. Yeah.
AndroidUser00110001 said:
Thanks for the guide. Making GPE kernel was my next step in trying to get the GPE ROM to work on v510.
I just made guide for getting your Android build environment going if you want to use it on your blog or where ever.
http://forum.xda-developers.com/showthread.php?t=2629008
The problem with v500 is that it does not have fastboot so we can not flash kernel like how you can on v510.
Click to expand...
Click to collapse
I don't understand, what are the differences bettween the v500 and v510? they both have the same hardware, but not the same boot partition or something like that?
ayziaa said:
I don't understand, what are the differences bettween the v500 and v510? they both have the same hardware, but not the same boot partition or something like that?
Click to expand...
Click to collapse
The boot on the 500 cannot be fully unlocked.
This is not the appropriate place to ask that kind of question should be asked in general or in troubleshooting. Also, there are already many threads about this same question please use the search utility to find them. Thank you.
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
sleekmason said:
Yes, from here: http://forum.xda-developers.com/showthread.php?t=847265
I noted that boot was on block nncblk0p21 on our device, and not 22? better double check that. I tried it Anykernel as well to no avail when getting this set up. Fastboot is Awesome!
It's taxing to get it set up right. Seems like things change very often for the dependencies based on other package changes. I ussually go with testing but redid two partitions with stable. The 32 bit is just going to sit there, which seems kinda silly due to the need for extra packages in 64 to compile for 32 but whatever. Yeah.
Click to expand...
Click to collapse
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
darkassain said:
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
Click to expand...
Click to collapse
Thank you! Have you successfully used your script to push a kernel onto the 500 Or 510?
I would think this could be very handy for sharing a custom kernel for the 510, but would like to see somebody report a positive test result. Very cool!
sleekmason said:
Thank you! Have you successfully used your script to push a kernel onto the 500 Or 510?
I would think this could be very handy for sharing a custom kernel for the 510, but would like to see somebody report a positive test result. Very cool!
Click to expand...
Click to collapse
yes back before when there wasnt a overclocked kernel i basically used this to push it when i would compile just the kernel (didnt maintain so i now use dyn's)...
yes this is only for the v500 as this has the extra loki step, but it shouldnt be hard to modify so it does not do that extra step
darkassain said:
i was thinking of writing a tutorial about this as well for the v500 but this better than i would have done Well done...
Another tool that i ported to the lg g pad a bit back along with loki-doki...
Quick hint, dont bother with direct mmc naming as qcom (i dont know if the other chip makers do the same thing, as i have only had qcom devices) has given us a simple naming scheme...
should only be used by people who know how to use this,
Click to expand...
Click to collapse
Hi, can you just use a generic anykernel updater script too?
For example to flash a packed boot.img
Code:
run_program("/tmp/busybox", "dd", "if=/dev/block/platform/msm_sdcc.1/by-name/boot", "of=/tmp/boot.img");
run_program("/tmp/unpackbootimg", "-i", "/tmp/boot.img", "-o", "/tmp/");
run_program("/tmp/repack-ramdisk.sh");
run_program("/tmp/mkbootimg.sh");
run_program("/tmp/busybox", "dd", "if=/tmp/newboot.img", "of=/dev/block/platform/msm_sdcc.1/by-name/boot");
mako and flo can do like this.. I think HTC One as well, since they are all similar qcom chipsets maybe this device can too
poondog said:
Hi, can you just use a generic anykernel updater script too?
For example to flash a packed boot.img
Code:
run_program("/tmp/busybox", "dd", "if=/dev/block/platform/msm_sdcc.1/by-name/boot", "of=/tmp/boot.img");
run_program("/tmp/unpackbootimg", "-i", "/tmp/boot.img", "-o", "/tmp/");
run_program("/tmp/repack-ramdisk.sh");
run_program("/tmp/mkbootimg.sh");
run_program("/tmp/busybox", "dd", "if=/tmp/newboot.img", "of=/dev/block/platform/msm_sdcc.1/by-name/boot");
mako and flo can do like this.. I think HTC One as well, since they are all similar qcom chipsets maybe this device can too
Click to expand...
Click to collapse
thanks for reminding me the any kernel uploaded by me won't work as it doesn't parse Loki images xorrectly, I'll upload the correct one once I have access to my pc
darkassain said:
thanks for reminding me the any kernel uploaded by me won't work as it doesn't parse Loki images xorrectly, I'll upload the correct one once I have access to my pc
Click to expand...
Click to collapse
could you please re-post to a different thread rather than hijacking this thread, as your script does not work with the 510 currently and I do not want to go to get confused with my kernel how to. what started out to maybe become relevant apparently will not and so shouldn't be confused with what I'm doing here. I will be happy to try working with your script if you would open up an appropriate thread. Thank you.
Installed kenel and booted. Now to install trickster mod and fix the dang gamma.
gunnyman said:
Installed kenel and booted. Now to install trickster mod and fix the dang gamma.
Click to expand...
Click to collapse
Excellent!! Pleased to know that you are able to use it. Have you changed your gamma settings?
I did on mine and am pleased with the result. I'm using 248, 252, 255 using trickster mod What are you going with?
sleekmason said:
Excellent!! Pleased to know that you are able to use it. Have you changed your gamma settings?
I did on mine and am pleased with the result. I'm using 248, 252, 255 using trickster mod What are you going with?
Click to expand...
Click to collapse
havent messed around too much.
I had a thought about this and I think it would be awesome if we could incorporate faux123's bits for gamma and color control. His fauxcontrol offers much more granular control than trickster.
I'm thankful to have what we have, and THANK YOU for sharing it, but like any good geek I WANTS MOAR!!!!!
gunnyman said:
havent messed around too much.
I had a thought about this and I think it would be awesome if we could incorporate faux123's bits for gamma and color control. His fauxcontrol offers much more granular control than trickster.
I'm thankful to have what we have, and THANK YOU for sharing it, but like any good geek I WANTS MOAR!!!!!
Click to expand...
Click to collapse
me too! I'll look into it. There are other apps besides trickster to give you more control. I think at the kernel level everything we need is unlocked. And yeah, he knows his business like nobody else eh? I'm just persistent.

[Q] Compiling directly on Hardware

I've been working on porting Octave (command line only) to the m8 for a few days now. I have all of its' dependencies compiled now, except for SuiteSparse. It requires output from some components during compile (it first compiles one program, then runs it to generate some data, then uses the data to compile others.) Since I can't run these on a computer, I've created a toolchain to compile on the device itself. Surprisingly, I can get the compiler to run on the device. Unfortunately, I have to use ld to run anything. The command looks something like this:
~$ ld-linux.so /path/to/gcc/tuple-gcc
It outputs just fine. But I can't simply run
~$ tuple-gcc
I have added the path to PATH, but still can't figure it out.
To compile anything I need to specify CC, as well as the other tools, but I can't figure out how to do this if they have to be executed using ld.
Any ideas?
Also, for anyone trying to do this, many configure scripts require "ls -t".
The coreutils that are installed in the base system are extremely stripped down, and ls doesn't support many of its normal switches.
I have compiled coreutils and will be testing them shortly. Hopefully they don't also have to be executed using ld!
***UPDATE***
I now have a fully-working compiler, to compile on the hardware itself.
Will try to make the 10 post minimum soon, to post a tut.

[HELP] Compiling Android from source (sm-g360f)

Hi there,
I have Samsung Galaxy Core Prime LTE and I could not find any custom ROMs so I decided that I will try to compile it myself. I downloaded the LineageOS source code from git (cm 14.1), the device trees and kernel from here: github/MSM8916-Samsung, and the samsung vendor files from the extraxt-files.sh script. The qcom-common files from here: github/CyanogenMod/android_device_samsung_qcom-common. Then I set up the environment (source build/envsetup.sh), ran breakfast and everything went fine. And then came brunch... It's running for about 40-50 minutes, and then stopes because "ninja: build stopped: subcommand failed". Here's the output from my terminal: https:/ /drive.google.com/fi le/d/0Bzbi _UspTWqac3ZkV2RhRjJGeW8/view?usp=drivesdk (remove spaces - sorry for that, but I cannot add links yet)
If the ninja log is needed I will post it.
Can someone help me to understand the code and find out why it is failing?
(I am new to developing stuff, but I have already compiled programs back in the days, and I am familiar with Linux, which is my daily driver)
what version of linux are you using at the moment?
Ubuntu 17.04, but I have also tried it on 16.10 last week, and openjdk-8
wasowski02 said:
Ubuntu 17.04, but I have also tried it on 16.10 last week, and openjdk-8
Click to expand...
Click to collapse
I can't speak for others but I have not had success building anything android on 15.10,16.04,16.10... I always end up on a wild goose chase with all the compiling errors. I have consistently compiled without errors using 14.04 with oracle java 8 as that is what many of the manufacturers are using to make their own builds. If or oracle spits errors with 14.04 i try to use the rule of thumb and thats openjdk-6 and jre for LP, openjdk-7 and jre for MM and openjdk-8 for nougat builds but im only working on MM builds at the moment so your results may vary. Hope this helps a bit, just remember you can use sudo update-alternatives --display java to switch versions on the fly if needed and make sure you incorporate Google prebuilts as well. good luck ?
Sent from my LGLS676 using Tapatalk
Sands207 said:
I can't speak for others but I have not had success building anything android on 15.10,16.04,16.10... I always end up on a wild goose chase with all the compiling errors. I have consistently compiled without errors using 14.04 with oracle java 8 as that is what many of the manufacturers are using to make their own builds. If or oracle spits errors with 14.04 i try to use the rule of thumb and thats openjdk-6 and jre for LP, openjdk-7 and jre for MM and openjdk-8 for nougat builds but im only working on MM builds at the moment so your results may vary. Hope this helps a bit, just remember you can use sudo update-alternatives --display java to switch versions on the fly if needed and make sure you incorporate Google prebuilts as well. good luck ?
Click to expand...
Click to collapse
Then I will try 14.04 and see what happens. Thanks for help
@Sands207 Is there by any chance a site where you can learn to do this? Tutorial for noobs of sort.
Sent from my SM-N920P using Tapatalk
ninja_unmatched said:
@Sands207 Is there by any chance a site where you can learn to do this? Tutorial for noobs of sort.
Click to expand...
Click to collapse
Yes, luckily for us xda members we have our own Android college built right into xda https://forum.xda-developers.com/general/xda-university its a great starting point and rom compiling guide is also there. Its all aimed to help new folks find their way ? jump right in ?
If you need TWRP for it I have it. It was built by blaz3r64, but since AA51 is down I can upload it for you. I can confirm that it works on both the ST Galaxy Core Prime and the Boost Prevail LTE.
Sent from my XT1609 using Tapatalk
RealWelder said:
If you need TWRP for it I have it. It was built by blaz3r64, but since AA51 is down I can upload it for you. I can confirm that it works on both the ST Galaxy Core Prime and the Boost Prevail LTE.
Click to expand...
Click to collapse
So I have already downloaded the official TWRP, but thanks for your interest.
I have tried to compile using ubuntu 14.04 (with openjdk-8) as @Sands207, but I get this error:
Code:
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/bison/bison -d --defines=/home/karol/android/system/out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_y.h -o /home/karol/android/system/out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_y.cpp system/tools/aidl/aidl_language_y.yy"
/bin/bash: prebuilts/misc/linux-x86/bison/bison: No such file or directory
wasowski02 said:
So I have already downloaded the official TWRP, but thanks for your interest.
I have tried to compile using ubuntu 14.04 (with openjdk-8) as @Sands207, but I get this error:
Code:
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/bison/bison -d --defines=/home/karol/android/system/out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_y.h -o /home/karol/android/system/out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_y.cpp system/tools/aidl/aidl_language_y.yy"
/bin/bash: prebuilts/misc/linux-x86/bison/bison: No such file or directory
Click to expand...
Click to collapse
I recommend trying this keychain as it has full support for what you are attempting https://forum.xda-developers.com/showthread.php?t=3606941 I have tried it myself but Id recommend cleaning your build folder before incorporating them, maybe even a reboot as well. i had forgotten about this but it has far more tools than the normal keychain.
Sent from my LGLS676 using Tapatalk
---------- Post added at 04:29 PM ---------- Previous post was at 04:22 PM ----------
remember to select the right architecture ??
Sent from my LGLS676 using Tapatalk
Sands207 said:
I recommend trying this keychain as it has full support for what you are attempting https://forum.xda-developers.com/showthread.php?t=3606941 I have tried it myself but Id recommend cleaning your build folder before incorporating them, maybe even a reboot as well. i had forgotten about this but it has far more tools than the normal keychain.
Sent from my LGLS676 using Tapatalk
---------- Post added at 04:29 PM ---------- Previous post was at 04:22 PM ----------
remember to select the right architecture ?
Click to expand...
Click to collapse
So I downloaded the new toolchain/keychain/cross compiler (just to make sure - this is the same, yes?), but I cannot find how to choose it to compile android. The official post says:
Code:
# for arm64
export CROSS_COMPILE=$(pwd)/bin/aarch64-linux-gnu-
but as I'm not compiling the kernel I assume it is not what I need (I think) and
Code:
echo $CROSS_COMPILE
does not return anything by default. If I should have used the export function then which file should I choose, because there are many (-strip, -strings, -size, -run, etc.).
There is a directory called toolchain (it contains only binutils) in the folder containing the source code. Should I add a folder called gcc and put the files there? Or maybe I have to run brunch with some options or change an entry in a configuration/make file?
I use the aarch64 version, but not the newest (20170515 not 20170520).
wasowski02 said:
So I downloaded the new toolchain/keychain/cross compiler (just to make sure - this is the same, yes?), but I cannot find how to choose it to compile android. The official post says:
but as I'm not compiling the kernel I assume it is not what I need (I think) and
does not return anything by default. If I should have used the export function then which file should I choose, because there are many (-strip, -strings, -size, -run, etc.).
There is a directory called toolchain (it contains only binutils) in the folder containing the source code. Should I add a folder called gcc and put the files there? Or maybe I have to run brunch with some options or change an entry in a configuration/make file?
I use the aarch64 version, but not the newest (20170515 not 20170520).
Click to expand...
Click to collapse
I do think as you said you will need to run brunch but resetting up your build & source environment to use the new keychain as you attempted to switch from one keychain to the other as well may help if this doesn't work as well take a look at your build configuration. rc file and make sure you don't have double entries or the new keychain missing i usually import the prebuilts i need as I am using arm architecture at the moment but i either download the individual keychain i need and place it in my source folder when i setup my build environment to be added to the build along with my sources before i run lunch because my source folder is untouched by me besides that at that point. I'll be home in an hour or so I'm going to see if i can track down some info to help you get untangled but i do recommend downloading the folder and making a gcc folder with the toolchain folder for arm64 as you said and and adding it to your build ensuring it is clean besides what you need and adding it then attempt to compile again.
I'm​ not sure if I should use aarch64. I have an armv7-a-neon (so 64-bit) and the internet says that aarch64 and arm64 is pretty much the same, but maybe I am wrong and I should use arm instead. But I think that does not matter until I put the new toolchain both to the aarch64 and arm directory (I guess the compilation process will choose the right one automatically). So I've put the compilers into prebuilts/gcc/linux-x86/... folders, but should I delete the old compilers? And then run the environment setup again (all this stuff starts to make sense to me ?)
Sent from my SM-G360F using Tapatalk
wasowski02 said:
I'm​ not sure if I should use aarch64. I have an armv7-a-neon (so 64-bit) and the internet says that aarch64 and arm64 is pretty much the same, but maybe I am wrong and I should use arm instead. But I think that does not matter until I put the new toolchain both to the aarch64 and arm directory (I guess the compilation process will choose the right one automatically). So I've put the compilers into prebuilts/gcc/linux-x86/... folders, but should I delete the old compilers? And then run the environment setup again (all this stuff starts to make sense to me )
Sent from my SM-G360F using Tapatalk
Click to expand...
Click to collapse
Yes you should delete the old ones and set up your enviroment again and it should include them. Also yes the compile proccess should pick the correct one in your case as long as you include them and you have, you are heading in the right direction for sure. :good:
Sands207 said:
Yes you should delete the old ones and set up your enviroment again and it should include them. Also yes the compile proccess should pick the correct one in your case as long as you include them and you have, you are heading in the right direction for sure. :good:
Click to expand...
Click to collapse
So I deleted the old ones and I get this error:
Code:
ninja: error: 'prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/arm-linux-androideabi-strip', needed by '/home/karol/android/system/out/target/product/coreprimeltexx/obj/lib/libdl.so', missing and no known rule to make it
I guess it's because somewhere in a configuration file there is an entry for the old compiler. I have deleted the out directory and played with the envsetup.sh file (about line 210 there is something about compilers),
Code:
# defined in core/config.mk
targetgccversion=
targetgccversion2=
export TARGET_GCC_VERSION=$targetgccversion
# The gcc toolchain does not exists for windows/cygwin. In this case, do not reference it.
export ANDROID_TOOLCHAIN=
export ANDROID_TOOLCHAIN_2ND_ARCH=
local ARCH=$(get_build_var TARGET_ARCH)
case $ARCH in
x86) toolchaindir=x86/x86_64-linux-android-$targetgccversion/bin
;;
x86_64) toolchaindir=x86/x86_64-linux-android-$targetgccversion/bin
;;
arm) toolchaindir=arm/arm-linux-androideabi-$targetgccversion/bin
;;
arm64) toolchaindir=aarch64/aarch64-linux-android-$targetgccversion/bin;
toolchaindir2=arm/arm-linux-androideabi-$targetgccversion2/bin
;;
mips|mips64) toolchaindir=mips/mips64el-linux-android-$targetgccversion/bin
;;
*)
echo "Can't find toolchain for unknown architecture: $ARCH"
toolchaindir=xxxxxxxxx
;;
esac
but this did not work either. The ninja files don't contain any gcc configuration. So where can I find the right configuration file? (I can't find the suggested configuration.rc file)
wasowski02 said:
So I deleted the old ones and I get this error:
I guess it's because somewhere in a configuration file there is an entry for the old compiler. I have deleted the out directory and played with the envsetup.sh file (about line 210 there is something about compilers),
but this did not work either. The ninja files don't contain any gcc configuration. So where can I find the right configuration file?
Click to expand...
Click to collapse
I usually compile using clang or maven as I only build AOSP atm https://ninja-build.org/manual.html this page includes directions that should assist you. Do you have maven or clang installed on your linux box?
Sands207 said:
I usually compile using clang or maven as I only build AOSP atm https://ninja-build.org/manual.html this page includes directions that should assist you. Do you have maven or clang installed on your linux box?
Click to expand...
Click to collapse
So it seems that nor klang nor maven is installed on my machine (but as my computer claims ninja is not installed either I guess that they may be installed somewhere in the build directories). Should I try them instead of ninja?
wasowski02 said:
So it seems that nor klang nor maven is installed on my machine (but as my computer claims ninja is not installed either I guess that they may be installed somewhere in the build directories). Should I try them instead of ninja?
Click to expand...
Click to collapse
yes absolutely
Sands207 said:
yes absolutely
Click to expand...
Click to collapse
So what I understand is:
(1) Install maven or clang (let's say clang because I found it in the official ubuntu repository)
(2) Configure brunch to use clang instead of ninja
So I checked the internet if there are any options I can use with brunch to run clang, but I didn't find any. Also looked through the envsetup.sh file, but there is nothing there, or I missed it.
wasowski02 said:
So what I understand is:
(1) Install maven or clang (let's say clang because I found it in the official ubuntu repository)
(2) Configure brunch to use clang instead of ninja
So I checked the internet if there are any options I can use with brunch to run clang, but I didn't find any. Also looked through the envsetup.sh file, but there is nothing there, or I missed it.
Click to expand...
Click to collapse
tonight i will try doing some digging to see if i can help you. im away from my computer right now but ill do what i can. i would try would maven. clang assists with aosp primarily but maven should work for you as far as using a custom command to run maven, log out or reboot after you install it and run brunch as you normally would also please read this https://clang.llvm.org/comparison.html

Categories

Resources