yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] sidneyk:
OK, I just did another Omnirom build for Asus tf101 with Linaro-4.7 tool chain and the only changes in flags as follows in /build/core/combo/TARGET_linux-arm.mk :

TARGET_arm_CFLAGS := -O3 \ <<<

Changed this from the normal setting

-fomit-frame-pointer \

-fstrict-aliasing \

-funswitch-loops

# Modules can choose to compile some source as thumb.

TARGET_thumb_CFLAGS := -mthumb \

-O2 \ <<<

Changed this from the normal setting

-fomit-frame-pointer \

-fno-strict-aliasing

No other changes. Play Store works and looks great. Both my internal and external ext4 formatted storages are visible and usable without any weird perms quirks going on. And, overall, it feels pretty snappy. Also, this was a user debug build. So, it seems the storage issue I mentioned earlier is caused by one or more of the optimization flags, other than the above changes to -O3 and -O2. Also, ART is working fine with this.
[Android Software/Hacking General [Developers Only]] linuxxxx:
Can I use this toolchain to build cm9?
[Android Software/Hacking General [Developers Only]] metalspring:
Or just ccache -c -C will work
[Android Software/Hacking General [Developers Only]] F4k:
I agree, ccache -C should be the right way.

Sent from my GT-I9190
[Android Software/Hacking General [Developers Only]] prstorero:
Alright so with the 4.7 toolchain things compile fine, but when I add the commit from [MENTION=3306843]kantjer[/MENTION] that applies the flags to TARGET_Linux-arm.mk it always errors out with "obj/SHARED_LIBRARIES/libmmcamera_interface_intermediates/src/mm_camera.o] Error 1" so since this only happens after doing the commit, do you know which flag may be causing this to happen? I looked at them but I'm not sure which if any have anything to do with the camera.
[Android Software/Hacking General [Developers Only]] k2wl:
ccache -C or ccache -c
[Android Software/Hacking General [Developers Only]] metalspring:
I find using both helps clear it faster, also I don't think ccache -c would be good enough to clear the cache when switching toolchains

ccache -c means cleanup which basically just removes while ccache -C actually means to clear the entire cache.

So either ccache -c -C or just ccache -C is what you should use to clear it when switching toolchains
[Android Software/Hacking General [Developers Only]] rodman01:
I tried it with only your changes and it compiled good. But at the end, when it trys to create the ota-xxx.zip the build stopped with Error 1. Tried it for the i9305 and the P1000. For both I haven't got rom.zips at the end. Any idea or/tip, what I could and should change to get the builds ready? Thanks in advance!
[Android Software/Hacking General [Developers Only]] sidneyk:
You did make 2copies of the tool chain, appropriately named the same as the 2 default 4.7 tool chains? Unless, of course, you started with tool chains where they were already separated out to 2 folders, i.e. arm-eabi-4.7 and arm-linux-androideabi-4.7? I don't know what error 1 is right off, but you may also have to increase your recovery.IMG size in BoardConfig.mk to complete a build. If that's the case, just don't try to flash the recovery.IMG because it will likely be too big. Otherwise, I don't really know. The rest of the error message related to that error 1 would be helpful.
[Android Software/Hacking General [Developers Only]] qwertyujhgfdsa:
Try this commit https://github.com/DJL10-2/android_external_bash/commit/1ff746e4ce40ed7b58598b63f05b036f5b2b3120

Then "make clobber" and start build again :)
[Android Software/Hacking General [Developers Only]] JustArchi:
With one condition, sourcing envsetup.sh before :).

root@ArchiDroid:~# which ccache
root@ArchiDroid:~#
[Android Software/Hacking General [Developers Only]] sidneyk:
OK, I found the culprit, in my case, that is the cause of the internal /sdcard disappearing and other strange storage issues. It is the -O3 flag for the thumb parts. When it is built with TARGET_thumb_CFLAGS := -O2 or below there are no storage issues. Here are the only changes made, building again Omnirom for Asus tf101, wtih Linaro 4.7 tool chains:

TARGET_arm_CFLAGS := -O3 \ <<<

Changed this from the normal setting

-fomit-frame-pointer \

-fstrict-aliasing \

-funswitch-loops

# Modules can choose to compile some source as thumb.

TARGET_thumb_CFLAGS := -mthumb \

-O3 \ <<<

Changed this from the normal setting

-- This causes internal /sdcard (/data/media/) to disappear on tf101 and other storage issues.

-fomit-frame-pointer \

-fno-strict-aliasing
[Android Software/Hacking General [Developers Only]] JustArchi:
This indicates a problem with one of the flag O3 uses. Glad you found a culprit, will add to the OP.

If you still have enough energy to make some tests, we could try to find a real culprit.

-finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-after-reload, -ftree-loop-vectorize, -ftree-slp-vectorize, -fvect-cost-model, -ftree-partial-pre -fipa-cp-clone

Here are the flags that O3 enables (not all of them, but the most). You can try to set O3 for target thumb and disabling one-by-one every "additional" flag O3 enables.

So you need to test:

-O3 -fno-inline-functions

-O3 -fno-predictive-commong

-O3 -fno-gcse-after-reload

...

-O3 -fno-ipa-cp-clone

This way it may be possible to disable only one specific O3 flag and not the whole optimization pass. Of course it's up to you if you want to find out the culprit.
[Android Software/Hacking General [Developers Only]] metalspring:
Hmm, for me it just works without running envsetup.sh, maybe it depends on how you have your build machine set up though
[Android Software/Hacking General [Developers Only]] JustArchi:
If you have ccache binary (apt-get install ccache) then it will work right away, however it's not a requirement for compiling AOSP, as it provides ccache on it's own.
[Android Software/Hacking General [Developers Only]] sidneyk:
Thanks . I'll keep looking into it as I get time to. These clean builds take a long time to complete. I have to share the pc with my wife who's addicted to her Facebook games. But, yes, this fits with my nature to troubleshoot things. Thanks for the info.
[Android Software/Hacking General [Developers Only]] prstorero:
[MENTION=3306843]kantjer[/MENTION] I'm not sure what causes this, but it's very strange. I did a make clean and built things fine. I added each commit one by one and rebuilt without a make clean and they each did fine. So i finally did a make clean and built with the same commits that were working, and now it just errors out. It seems I just can't do a clean build with even a single commit otherwise it just gives an error. Won't it work just fine without doing a clean build? Because obviously they won't work for me at all. Unless you have any ideas.
[Android Software/Hacking General [Developers Only]] JustArchi:
ALWAYS make clean AND empty ccache when you're messing up with the flags. ALWAYS.

Build flags are applied to every part of an Android, and by not cleanly rebuilding you're asking for troubles and having half-optimized buggy build. It's not a typical java commit that you can apply, rebuild one apk or framework and move along... This is not connected with java at all, it's connected with the C and C++. If you can't handle cleaning your build on every flag change then you probably shouldn't even read this thread. And I'm serious, you need to put some time into this commit if you want to get satisfying results.

And you don't need to compile a hundred of builds as I did. Usually it's enough to compile a build with:

1. Not touching any O flag. This includes keeping O2 for target arm, Os for target thumb and O2 for global target release (in select.mk). These are stock O flags.

2. "Bumping" all O2 flags to O3. This includes O2 -> O3 for target arm and global target release (in select.mk)

3. Major bump of target thumb's Os to O3.

First and second step is fairly easy and shouldn't cause any major issues if done properly. Last step is the most complicated, as it's applied to the most Android parts (the "biggest" android parts), therefore it optimizes the most, and causes the most issues.

TL;DR - Cherry-pick my commit and change TARGET_thumb_CFLAGS's -O3 back to -Os before even trying this.

O3 works in my case, with my phone, and with the Omni which is very close to AOSP in terms of C and C++. Therefore, Android could be optimized fully with O3 flags. However I can't assure you that CyanogenMod and various device-specific android components will like O3. Usually, keeping thumb CFLAGS on Os solves 99.9% of issues, which are not caused by the compiler and it's version itself.

Again, this is not a something that you can cherry-pick and forget. It's not a typical commit that could be submitted on a gerrit. It's a masterpiece, which requires adapting to your own ROM and device. After doing so, you and your users will benefit from it.

On topic: V3 is near. I'm testing the last flag right now.
[Android Software/Hacking General [Developers Only]] prstorero:
I appreciate the insight. It came off a little harsh (I thought), but I don't think you meant it to be. I'm compiling with Slim which I believe is pretty close to AOSP. I know Kantjer has built for Slim with these, so they should be able to work, though that was for the S4 and I'm doing the Nexus 5. I did a make clean (as I was doing before) and did a ccache clear as well. I'm attempting a build with just the changes in Target_linux-arm.mk) so I'll see how that works out. I kept getting an error of mm_camera somewhere in the target directory (don't remember the exact location now). So I guess if this doesn't work I'll reduce the -o3 flags and see what happens. I know you mentioned reducing the thumb CFLAGS to Os, but if that's the 90% of android, doesn't the defeat the optimization that's being aimed for? I know it may not work with what I'm building, so I may just not have a choice. I'm always willing to learn but I haven't come across much that's helpful with fixing errors like I was getting except doing a make clean, which did nothing. Though before I wasn't doing a ccache clear after the make clean either, so that may be what the problem is.
[Android Software/Hacking General [Developers Only]] JustArchi:
I didn't want to be harsh, just nowadays people are blindly applying various tweaks without even looking what they're doing :). My reply wasn't targeted at anyone.

With upcoming V3 it will be a bit easier to make changes.

Also, unfortunately, Slim is CM's fork, and while CM may look from enduser experience as "AOSP", it's not. Modifications made to AOSP sources at current state are huge and while it's still nothing major because most of them include only APKs and java things we don't touch, still, they also have some bionic/art/dalvik/other changes, which are affected.
[Android Software/Hacking General [Developers Only]] prstorero:
No problem man I know it can be frustrating. I actually do look up the commits to look at them, but I really don't understand them very well lol. Since I only started compiling less than a week ago, I obviously don't know much, but i would love to learn, as I'm trying. Should I just wait for V3 before getting more frustrated? :P

---------- Post added at 09:25 PM ---------- Previous post was at 09:15 PM ----------

So does that mean I probably won't be able to take full advantage of your work due to Slim being different?
[Android Software/Hacking General [Developers Only]] JustArchi:
V3 Live.

https://github.com/JustArchi/android_build/commit/0cf89401cc8092dda959b5746ec4899fda756cec

"Changelog":

For #1s you should thank [MENTION=4328678]metalspring[/MENTION], as I cherry-picked them from his repo barely making any changes.

About #2 - Even if still nobody has proven that strict-aliasing for all targets cause any major issue, I decided to keep them off for now because honestly I think that it's not worth it. Maybe in future if Linaro team fixes all strict-aliasing issues in AOSP tree, we could turn it back on and be 100% sure that it won't cause any issues.

In general, it's not a "big thing", because well, look at the commit, I did a "big thing" before a public release so there's little to none to optimize further.

I've tried to add LTO optimizations but I failed, even for target ARM. Maybe in future, as for now it's impossible. [MENTION=4328678]metalspring[/MENTION] - I noticed LTO optimizations in your build, but you didn't add -Wl,-flto LDFLAG, therefore your flto optimization is not doing anything because linker doesn't even check special ELF section generated by GCC.

V3 also features some comments and a link to the thread. Cosmetic things.
[Android Software/Hacking General [Developers Only]] prstorero:
Thanks for the update. I'll be giving this a shot if this build fails :)
[Android Software/Hacking General [Developers Only]] Kurre:
Sorry, but slim (assuming you guys are still talking about SlimKat) is AOSP based. For some devices there might be stuff from CM, but nevertheless it's still AOSP based [emoji6]

Dunno where this assumption it being CM-based comes from, as it's still being asked in some threads for time to time..and always someone says that it's CM based (which is just plain false information).

I don't know if there's something picked from CM repos which might affect while using your commits..for that one should look the git or ask slim devs [emoji2]

Sent from my Nexus 4
[Android Software/Hacking General [Developers Only]] Wombatino:
Actually, slimkat for devices like Nexus 5 are almost 100% based on AOSP
[Android Software/Hacking General [Developers Only]] ne0zone75:
Hello, FYI i've successfully applied straight [MENTION=5161352]JustArchi[/MENTION] V2 optimizations on SlimKAT build 5.4 (target devices : serranoltexx & serrano3gxx, ROM is built for both ones and is running well) ;)

BTW, i've encountered a module build failure during first build try (libhwcomposer) like yours; i solved it by appending '-Os' at the end of the 'LOCAL_CFLAGS', maybe tuning directly the module flags of your failing camera module is a solution for you... (not 'JA' ones)

Best regards,

PS 1 : thanks [MENTION=3261191]F4k[/MENTION] for giving us this tip :D

PS 2 : it seems there is no 'Play Store' display bug anymore with Linaro 4.8.3 20140401 synced from 'android.git.linaro.org'... :good:
[Android Software/Hacking General [Developers Only]] :
just build crdroid with your V2 script and new sabermod 4.8.4 toolchain, feels good and fast

going to try with sabermod 4.9.1 and see what happends

i'll try V3 later

can anyone suggest a good and reliable benchmarking tool?
[Android Software/Hacking General [Developers Only]] JustArchi:
Good for you then, because if I can build Omni with it, then it's very likely that SlimKat will be fine as well.

There's none, you can use benchmarks like Antutu and other Quadrants, but Android is not a benchmark, it's operating system. That's why I tested pure speed of Os, O2 and O3, then compiled whole ROM with O3 and gave it to the users for blind tests. 9 votes for O3 in terms of performance compared to 1 vote on Os. This blind test is enough for me to say that it "makes a difference".
[Android Software/Hacking General [Developers Only]] denzel09:
Hi, can you link me these two prebuilt sabermod toolchain, 4.8.4 and 4.9.1 ?

Thanks
[Android Software/Hacking General [Developers Only]] kantjer:
This is 4.8.3, I haven't seen 4.8.4 yet.

I would not go for 4.9.1, it's not stable and development is stopped. I haven't been able to build the ROM with SM 4.10 (kernel build was OK with SM 4.10)
[Android Software/Hacking General [Developers Only]] :
4.8.4. is out , check there github

here the prebuilts of 4.8.4. and 4.9.1.

i'm gonna build 4.10 tonight

arm-eabi-4.8

arm-linux-androideabi-4.8

arm-eabi-4.9

arm-linux-androideabi-4.9
[Android Software/Hacking General [Developers Only]] denzel09:
Edit: previous message

---------- Post added at 03:31 PM ---------- Previous post was at 03:26 PM ----------

Thanks. These posted previous by kantjer here https://bitbucket.org/Cl3Kener seem to be the same at the end right ?

I see 9 may last commit in SM 4.1 in Cl3Kener repo.
[Android Software/Hacking General [Developers Only]] :
check SaberMod github
[Android Software/Hacking General [Developers Only]] Silesh.Nair:
Make it 10. Compiled Gummy ROM for Mega 6.3 with v3/sabermod 4.8.3/user variant and the difference is very visible. Just awesome.
[Android Software/Hacking General [Developers Only]] denzel09:
Thanks.

I ll try also with your tonight bulid of SM 4.10
[Android Software/Hacking General [Developers Only]] nasty007:
Im trying to build Resurrection Remix for maguro but im stuck at this error and cant pass this

http://pastebin.com/hzxJpnmf
[Android Software/Hacking General [Developers Only]] JustArchi:
Update your BuildBox to latest Debian or Ubuntu. This problem is directly connected with the Linux.
[Android Software/Hacking General [Developers Only]] nasty007:
ok, thanks im using Linux Mint 16
[Android Software/Hacking General [Developers Only]] prstorero:
I have a friend that suggested I use 15 because 16 had some issues with building. I'm using 15 and have had errors, but I don't think they're related to the version. I'm not sure how accurate it is, but that's just what I heard.
[Android Software/Hacking General [Developers Only]] JustArchi:
I'm always using Debian Testing and it works awesome.
[Android Software/Hacking General [Developers Only]] F4k:
On Mint16 x64 never had any issues when bulding.

Sent from my GT-I9190
[Android Software/Hacking General [Developers Only]] prstorero:
Well like I said it was just the one. Plus he runs it on a VM so that could very well be the issue.
[Android Software/Hacking General [Developers Only]] denzel09:
Hi compiling with last 4.9 i see in compile.h:

#define LINUX_COMPILER "gcc version 4.10.0 20140427 (experimental) (SaberMod-4.10.0_android-graphite) "

Why it's seen like 4.10 ?

my wrong.
[Android Software/Hacking General [Developers Only]] kantjer:
Using Builduntu on VM, never any problems. Works straight out of the box, all building tools are included. I only have to download my toolchain of choice if I want to use anything else than Google.
[Android Software/Hacking General [Developers Only]] prstorero:
Interesting. Well since I've already been running 15 I don't think there's any sense in updating to 16 :)
[Android Software/Hacking General [Developers Only]] kirmaniarslan:
Thanks Sir I have managed to compile Cm-11 with ur ArchiDroid Optimizations method and it has desperately increased performance and smoothness on a legacy device Htc Pico . It has been tested by many users and all of them gave me a positive response.
[Android Software/Hacking General [Developers Only]] :
for who wants it: SaberMod 4.10 prebuilts:

arm-eabi-4.10

arm-linux-androideabi-4.10
[Android Software/Hacking General [Developers Only]] irocevo:
I am trying building CM11 with V2 Optimizations for m7spr with linaro gcc 4.8

I keep getting these errors:

kernel/htc/msm8960/net/bluetooth/hci_conn.c:407:28: warning: argument to 'sizeof'
in 'memcpy' call is the same pointer type '__u8 *' as the destination; expected '__u8' or an explicit length
[-Wsizeof-pointer-memaccess] error, forbidden warning: hci_conn.c:407

....................................
kernel/htc/msm8960/drivers/usb/gadget/f_qdss.c:586:38: warning: argument to 'sizeof' in 'strncmp' call is the
same expression as the second source; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]

I believe the fix is to add this:

-Wno-sizeof-pointer-memaccess

I'm just not sure were I should add it.
[Android Software/Hacking General [Developers Only]] JustArchi:
And you're right. It is the kernel. so the right place is in TARGET_arm_CFLAGS.
[Android Software/Hacking General [Developers Only]] prstorero:
Alright so I'm glad to say I got a build going with [MENTION=5161352]JustArchi[/MENTION] V3 commits and gcc 4.8 toolchain for Slim. Though I did unfortunately have to decrease thumb from -O3 to -Os. I have a question regarding it. I know in the OP you mention the performance of -Os is 2.5X worse than -O2, but since your flags are still built with, just with a lower level of optimization, is the difference in performance really noticeable? I would love to get thumb to -O3 but it doesn't seem possible in my case, or I just don't know how to handle the error.
[Android Software/Hacking General [Developers Only]] denzel09:
Kernel compile good with 4.9/4.10 but only with eabi, with both androideabi i have always some mismatch errors in kernel.
[Android Software/Hacking General [Developers Only]] JustArchi:
It is. O is the most important flag, which itself specifies a dozen of variables and other flags. In fact, it's more important than all other flags combined. By decreasing O3 from THUMB target back to Os you're losing major portion of optimizations.
[Android Software/Hacking General [Developers Only]] sparksco:
-Os is not less optimization per say. If it was really that terrible Google wouldn't use it. -Os is just for optimize for size. So it reduces the size of the compiled code. Some people can argue that size is not a concern for storage which is true. But the increased code size also increases memory usage and in most case more battery drain because of the high memory usage. I always use -Os for thumb to keep my memory usage down.
[Android Software/Hacking General [Developers Only]] prstorero:
Bummer. Maybe I'll give -O2 a shot then and see if it gives me an error too.
[Android Software/Hacking General [Developers Only]] JustArchi:
I didn't notice any excessive memory usage. In fact, my best score is ~550 MB free (after boot) with Os and about 540 MB free (after boot) with O3. So yeah it will use some extra megabytes for loading larger binaries and other parts, but I disagree that it will decrease battery life. In fact, my battery life improved since I switched Os to O3, and this is due to the fact that CPU is doing tasks 2-3x times faster compared to Os, while just "keeping" some extra megabytes doesn't hurt anyone. While I agree that operating on memory uses some power (because, well, everything uses some power), I strongly disagree on battery drain part, because it is the CPU, which drains the most, and with O2/O3 improvements it's just faster with same amount of power. It can't drain more battery than Os if we're doing the same tasks 2-3x times faster on identical power level.
[Android Software/Hacking General [Developers Only]] JustArchi:
Definitely it's worth a try. O2 is the best option for memory usage, code size and performance balance. O3 will increase code size compared to O2, while it may or may not, give any benefits. However, in my case, code size difference between O2 and O3 is so little, that even if O3 gives a very small boost to at least one part, it's worth it. Especially because we can't go "higher", as Android is not compatible with -Ofast and O3 is the max we can specify for the whole project.

Both O2 and O3 are great, I've been using O2 for a long time before I decided to go with O3. The biggest leap in terms of optimizations is inside -Os -> -O2 change in THUMB target. This is the main reason why the whole system is that fluid after applying my commit. This little change is about a half of real boost in my commit, the other half is the proper compiler and GCC 4.8. Massive amount of F flags is more like a final polishing to O3 and not a something that important. If somebody asked me where is the magic in this commit, it is O3 for target thumb AND Linaro/SaberMod 4.8 (instead of default GCC 4.7). This is the core.
[Android Software/Hacking General [Developers Only]] sparksco:
With all my test -O3 always causes more battery drain. To each their own. I just can't sit by while people make blatant statements that "-O3 has more optimizations". It does have " different" and maybe more as in the number of flags used. That doesn't get mean it gets "more optimized", just optimization with different flags...