yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] KcLKcL:
Your RAM is only 4GB, that could be why. I immediately bought 8GB RAM when I saw how cheap it was 2 years ago, now the price has risen again :|
[Android Software/Hacking General [Developers Only]] noname55804:
Hey,

First of all I didn't read through the whole thread, only the last pages so I apologize if my question has already been discussed. I'm building a ROM based on liquid smooth and want to use this optimisations as they sound very powerful. I started to add the archi toolchain 4.8 to my roomservice.xml and changed the target_gcc in target_Linux_arm to 4.8 (before it was 4.7.1-sm. The compilation ran without any issues but I don't know if the toolchain has applied correctly as I can't see any difference in the kernel name. Its still GCC saber mod 4.10 since this is the stock toolchain in liquid smooth. Must this name change or how can I checke if I aplllyied the toolchain correctly? Do I have to remove toolchain parts in my manifest?

And the next thing I wanna ask is if the Optimisation commit is needed on liquid? This has been discussed a few pages back I saw but I think there wasn't a convincing answer.

Help would be greatly appreciated :)
[Android Software/Hacking General [Developers Only]] desalesouche:
when your build will be finish, you can check after flashing rom what gcc for rom and kernel have been used....

i do that with antutu benchmark generally...it has an option to show device spec etc...
[Android Software/Hacking General [Developers Only]] noname55804:
Sorry but how to get to this option. I may be blind but didn't find it
[Android Software/Hacking General [Developers Only]] desalesouche:
open antutu bench apk go to device info

ans see what it says about kernel
[Android Software/Hacking General [Developers Only]] bigsupersquid:
you changed the ROM gcc but not kernel.

that's more like ARM_EABI_TOOLCHAIN := $(ANDROID_BUILD_TOP)/prebuilt/linux-x86/toolchain/arm-eabi-4.8/bin

(check the path and correct it to match where your roomservice.xml puts your chosen arm-eabi toolchain.)

and it goes in BoardConfig.mk for your device.

You can see what version was used to build the kernel with

dmesg | grep -i gcc

(terminal or adb has to be root to get dmesg)
[Android Software/Hacking General [Developers Only]] noname55804:
Ah OK thanks :) Will try that asap and tell you the result.

Can I somewhere checked with which GCC the ROM was compiled?
[Android Software/Hacking General [Developers Only]] frap129:
This didn't work, got the exact same error. To see if it was a problem with the source I was using (in this case, carbon) I had someone else using carbon try to see if they could compile with it for their devices. The result was this;
[Android Software/Hacking General [Developers Only]] JustArchi:
If you're judging this commit based on antutu benchmark then yeah, it's better for you to stay away from them. Can't understand why people bring this unreliable piece of crap benchmarking HARDWARE to software optimizations, then saying that it's "not worth it" :eek:.
[Android Software/Hacking General [Developers Only]] marcomarinho:
This is insame! 17GB of swap and still getting that error :(
[Android Software/Hacking General [Developers Only]] frap129:
Didn't mean to upset you, just going by someone elses findings, not mine. I'm going to continue to try to get this working so I can see for myself. Im sorry If I offended you.
[Android Software/Hacking General [Developers Only]] desalesouche:
sorry to bother here but i have some errors i can't fix by myself buiding liquid smooth and gummy rom...and i believe here we have specialist...;)

the warning is shown at the beginning of the build---->

build/core/binary.mk:427: target '/home/desalesouche/gummyrom/out/target/product/u8860/obj/SHARED_LIBRARIES/libstagefright_intermediates/LPAPlayer.o' given more than once in the same rule

and the horrible errors come:

http://pastebin.com/V1wU20n5

please help? gcc rom : 4.8 and kernel =linaro 4.9.1

thanks a lot
[Android Software/Hacking General [Developers Only]] frap129:
Then a lack of RAM/Swap probably isnt the problem. I've compiled just fine using no swap, only 8gb of ram and Archi's linaro 4.8 for both rom and kernel, as well as 4.8 for rom and UBERUTILS 4.9 and 4.10 for the kernel.

---------- Post added at 05:59 PM ---------- Previous post was at 05:57 PM ----------

Did you make sure to make clean/clobber and delete .ccache? I had a simillar error originaly but doing that fixed the problem
[Android Software/Hacking General [Developers Only]] marcomarinho:
BIONIC guys! BIONIC!

So I hate myslef. Sometime ago I played with bionic. And that's why I got that annoying error. Two weeks! Twos weeks installing new os asking to everyone, searched everything, what a **** :(

But let's think possitive: I finnaly fixed my error :victory:
[Android Software/Hacking General [Developers Only]] JustArchi:
I don't feel offended, I feel sad for people using hardware benchmarking tool instead of doing software compile test (similar to mine in OP).

This commit is not made to give more raw power to GPU or CPU. It's meant to make OS more responsive by minimizing overhead and required job to finish certain tasks.

Using benchmarks like Antutu is simply POINTLESS because this commit is not even meant to increase raw phone power. It's like judging restaurant's food by it's name.
[Android Software/Hacking General [Developers Only]] KcLKcL:
Well, my Nexus 4 benchmark went up like 3000 on V5, and 8000 on V4.

But on my brother's Xperia L, the scores are the same. But it is indeed smoother =]

I don't judge based on benchmark though, I judge based on actual user experience :)
[Android Software/Hacking General [Developers Only]] desalesouche:
hi. I do make clobber before each build and after each change and rebuild... .ccache is for now not installed...

i have that problem only with liquid smooth and gummy rom...

i builded about ten differents booting roms... and i builded more....

each time with about same device tree....

so from my point of view it is sources"fault"

any others idea?

thank for answer
[Android Software/Hacking General [Developers Only]] noname55804:
Should it look like this when the right toolchain is applyied?
[Android Software/Hacking General [Developers Only]] JustArchi:
Yep, this indicates that you built with Linaro.
[Android Software/Hacking General [Developers Only]] noname55804:
Cool, thanks! But my Camera didnt work, thats normally a toolchain issue right? Will try using your 4.9 toolchain. Di i have to edit roomservice.xml for that or just change TARGET_GCC?

And which commit would you recommend for Liquid Smooth Rom? Omni or CM?
[Android Software/Hacking General [Developers Only]] JustArchi:
Camera is device-specific. No clue why it doesn't work, as mine does.

If you want to change your toolchain, you need to make sure that:

a) You added two repos (arm-linux-androideabi and arm-eabi) to proper dirs

b) You changed TARGET_GCC_VERSION to the proper version implied by above dirs

Use https://github.com/JustArchi/Toolchain for newest Linaro (linaro-4.9 branch, it's from 3 September), in fact I'll add older linaro 4.8 to this repo soon, and then make JustArchi/Linaro repo as obsolete/deprecated.
[Android Software/Hacking General [Developers Only]] 95A31:
[MENTION=5161352]JustArchi[/MENTION]

Hi, probably Google Store glitch is due this https://android.googlesource.com/platform/external/webp/. Form readme:

The Android.mk file creates WebP Decoder and Encoder static libraries which
can be added to any application by Adding to LOCAL_STATIC_LIBRARIES
libwebp-decode libwebp-encode:

LOCAL_STATIC_LIBRARIES += libwebp-decode libwebp-encode

I find out that skia exploit it. Can you overwrite libskia from working ROM in order to test my idea?

If it is working the fix is adapt this workaround in order to use libwebp-* precompiled with GCC 4.8.0.
[Android Software/Hacking General [Developers Only]] noname55804:
Compiling a stock liquid smooth rom right now to see if its not their repo which broke the cam.

EDIT: Yes it was the LS repo taht broke it, sorry :/

Right now i´m using those entries in roomservice and BoardConfig:

roomservice

<!-- LINARO TOOLCHAIN -->
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />

BoardConfig:

TARGET_GCC_VERSION_ARM := 4.8
TARGET_GCC_VERSION_AND := 4.8

So if i wanna use your newest 4.9 linaro, which gives best performanc and stability i should change those entries to:

<!-- LINARO TOOLCHAIN -->
<project name="JustArchi/[COLOR="red"]Toolchain[/COLOR]" path="prebuilts/gcc/linux-x86/arm/arm-eabi-[COLOR="Red"]4.9[/COLOR]" remote="github" revision="[COLOR="red"]linaro-4.9[/COLOR]" />
<project name="JustArchi/[COLOR="red"]Toolchain[/COLOR]" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-[COLOR="Red"]4.9[/COLOR]" remote="github" revision="[COLOR="red"]linaro-4.9[/COLOR]" />

BoardConfig:

TARGET_GCC_VERSION_ARM := 4.[COLOR="red"]9[/COLOR]
TARGET_GCC_VERSION_AND := 4.[COLOR="red"]9[/COLOR]

RIGHT?

And what about your commits?
[Android Software/Hacking General [Developers Only]] JustArchi:
Right with one addition:

Use linaro-4.9-arm-eabi and linaro-4.9-arm-linux-androideabi branches.
[Android Software/Hacking General [Developers Only]] noname55804:
Thanks, totally missed that :)

What about your OPTIV3 commits when i wanna add them ro a liquid smooth repo would you recommend using the Omni or CM Version?
[Android Software/Hacking General [Developers Only]] JustArchi:
Holy crap mate you're a genius.

Using precompiled /system/lib/libskia.so from Google's 4.8 in fact fixed this issue! :victory:

Now the question remains WHY. Finally I have a starting point and perhaps I'll find out more soon.
[Android Software/Hacking General [Developers Only]] 95A31:
Ty :) This look like a good start point in order to look a fix libwebp

[MENTION=5161352]JustArchi[/MENTION]

Can you provide me libwebp-decode and libwebp-encode compiled with GCC 4.8 ?
[Android Software/Hacking General [Developers Only]] JustArchi:
https://github.com/JustArchi/ArchiDroid/raw/2.X-EXPERIMENTAL/_archidroid/auto/system/lib/libskia.so

Beware, this may be device-dependent.
[Android Software/Hacking General [Developers Only]] 95A31:
The issue start from libwebp-decode and libwebp-encode. libskia only include them.
[Android Software/Hacking General [Developers Only]] Codename13:
I've compiled unofficial CM10.2 for my device, with the ArchiDroid optimizations applied including the use of 4.8 GCC too. However, benchmarks are WAY worse. My device's AnTuTu score is usually around 5000 on CM10.2 but with ArchiDroid optimziations applied, the score is around 1000-2000. Anybody got an explanation for this? Is it the 4.8 GCC? BTW, I'm using the Linaro 4.8 GCC from JustArchi's Github repo. And FYI my device is called the Samsung Galaxy Ace II X (GT-S7560M).
[Android Software/Hacking General [Developers Only]] metalspring:
One thing, it might be the strict aliasing violations that are being ignore in ArchDroid's commit causing code issues (memory leaks, different parts of the code not executing properly, etc). Also, one thing to keep in mind, some optimizations may work great on a lot of devices, but then there may also be some devices that do not respond well to those optimizations too.

I'd say, for starters, try changing the Wno-error=strict-aliasing to Werror-strict-aliasing but that would definitely require a lot of extra commits to fix those violations, or you can try to change the -fstrict-aliasing to -fno-strict-aliasing (much easier but less optimized).

Also, those optimizations may not help performance at all on your version of android (different versions may respond to optimizations differently), or it may be just your device that doesnt like them. I'm not familiar with the galaxy ace II X but if its an older device you can also try changing the -O3 to -Os in TARGET_thumb_CFLAGS

-O3 makes compiled code larger, which may cause performance issues on older devices, which is why google uses -Os by default (optimize for size)
[Android Software/Hacking General [Developers Only]] Paul L.:
So, this was linked here. http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

Behaviour since GCC 4.7.x was that all warnings were treated as errors,

by default

, so when files cannot be compiled under the strict-aliasing rule, it will show a warning while compiling, and that warning will be treated as a error by the "-Werror" flag.

So, "-Wno-error=strict-aliasing" means "warnings about this are not an error = strict-aliasing", so when compiler detects that the source code files does not comply to the strict-aliasing rule, GCC will throw a warning, and it will not be treated as a error (which will stop compiling), file will not be compiled as strict-aliasing because it does not comply with the rule, and everything will continue smoothly, pretty much.

And yes, this is a rule, and you can enforce it, or not, if this could cause errors, you wouldn't have a choice to disable it at all. Compile without "-Wno-error=strict-aliasing", the file will not be generated and the compiler will stop at that point. With "-Wno-error=strict-aliasing", the file will be generated without strict-aliasing and joined on link-time by ld, and if there is something wrong there, compilation will stop because there is something wrong.
[Android Software/Hacking General [Developers Only]] sidneyk:
I applied your patches to my Omnirom build for the Asus TF101 (Tegra 2) tablet. I used your linaro-4.8 tool chains. It compiled fine and everything, so far, feels much faster, but one problem I've noticed is that now I have graphics corruption in the Playstore. It's the only place so far that I've seen this. This is a non-neon device, if that helps. I haven't tested any games yet or anything else with a lot of graphics as things didn't automatically restore after a clean wipe like they normally would for some reason. Are some of the flags and optimizations neon dependent?
[Android Software/Hacking General [Developers Only]] metalspring:
No, gcc definitely does not treat all warnings as errors, if it did compiling pretty much anything would be impossible (there are always tons and tons of warnings when compiling). Only when the Werror=(something) or Werror options are used will a warning result in an error. Wno-error simply means ignore any Werror options that would make that particular warning cause an error. I.e. Werror=strict-aliasing is directly canceled out by Wno-error=strict-aliasing.

To understand better, you have to understand what exactly those options do

Werror-strict-aliasing means "treat all strict aliasing violation warnings as errors"

Wno-error=strict-aliasing means "warn of strict aliasing violations but never treat them as errors"

Wno-error is most commonly used when the Werror option is present (treat all warnings as errors), where one or more warnings do not inhibit the integrity of the code so it is safe to ignore them in order to allow the build to finish.

The code will be compiled with the strict aliasing rule, however since it violates the strict aliasing rule, the resulting code may be very different than intended and not work properly
[Android Software/Hacking General [Developers Only]] Paul L.:
My very point was resumed on, the whole point of this was that the flag is meant to not to treat a strict-aliasing warning as a error, what I am sure about is that warnings since 4.6 are progressively being treated more as errors as part of their full compilance of C99 and C11; and to force developers to write or rewrite better code so they don't rely as much on what the compiler optimizes.

What I read on GCC mailing lists is that 4.9 (now stable), is a lot better now on code optimization, specifically on ARM, another thing to try.

Also, I would advise some developers to backport ARM erratas patches to their current kernels to correct bugs on certain SoCs as a general advice.
[Android Software/Hacking General [Developers Only]] bsmitty83:
this is paraphrased from Linaros blog :

Getting rid of -fno-strict-aliasing enables rather efficient additional optimizations – but requires that the code being compiled follows some rules traditionally not enforced by compilers.

Given the traditional lack of enforcement, there’s lots of code out there (including, unfortunately, in the AOSP codebase) that violates those rules.

Fortunately, gcc can help us detect those violations: With -fstrict-aliasing -Werror=strict-aliasing, most aliasing violations can be turned into built time errors instead of random crashes at runtime. This allowed us to detect many aliasing violations in the code, and fix them (where doable with reasonable effort), or work around them by enabling -fno-strict-aliasing just for a particular subdirectory containing code not ready for dropping it.

here is the entire article :

http://www.linaro.org/blog/android-...aro-android-2011-10-and-future-optimizations/

I would just like to know if this still applies since it was written in c.2011 ?
[Android Software/Hacking General [Developers Only]] desalesouche:
bump....with all theses experts talking, i hope i could get a little help to fix compile...

thanks...
[Android Software/Hacking General [Developers Only]] JustArchi:
Okay guys, let's keep it this way.

fstrict-aliasing and ignoring error didn't cause any problems to me, neither to any user of my ArchiDroid ROM for i9300 and ports with same commits for i9000 and i9305.

If you can prove, by whatever method you want, that it causes any problems in any place, I'll consider sticking with your ideology and disabling fstrict aliasing for whole target thumb.

Until then, as I can't find any problems, neither any of users and probably any of developers (at least now), I'm going to keep it. You don't need to agree with me, those who want to disable fstrict aliasing can do so by changing -fstrict-aliasing back to -fno-strict-aliasing, up to you.

I know that this is not a fix and that Linaro team implemented real fixes to strict aliasing in various Android parts, I don't deny that. If somebody wants, I highly suggest to take a look at them and apply if possible. But I can't agree on the fact that my fstrict-aliasing method causes any problems or is highly dangerous to anyone. If you can prove otherwise, please do so, nobody has been born with such knowledge, I'm just human as everybody of you and by proving me wrong you actually make me happy because I can learn something new.

Again, you don't need to agree with me, you can create your own commit with your own flags, nobody forces you to my ideology :). However, at least now I consider my method as totally safe.

Hope we can end this discussion this way.
[Android Software/Hacking General [Developers Only]] JustArchi:
As I told you mate, try other toolchains. I didn't face this error. If somebody will have a solution for you, he/she will write it. Until then, I really suggest to find out solution yourself. I shared most of my knowledge in the commit itself, including some fixes for ART, and the kernel. Applying those optimization flags is try-and-see. You try some flag, see if it compiles and doesn't cause problems. For example, -fipa-pta compiles without problems, but causes some strange audio issues and other problems (at least for me). However, no error was thrown. On the other hand, fstrict-aliasing does throw errors by default, but doesn't cause any problems. There's no rule - some roms may work right out of box with these optimizations, other may be forced to implement fixes or disable some flags.
[Android Software/Hacking General [Developers Only]] Neo:
No problems using the wno-error method on fireball, incredible, Rezound, M7, and T6 for me and my testers/users.
[Android Software/Hacking General [Developers Only]] DevSwift1:
Polacy są zdolni:)

anyway sorry for OT:P
[Android Software/Hacking General [Developers Only]] surdu_petru:
Hello !

First, let me say : [MENTION=5161352]JustArchi[/MENTION], thank you very much for your awesome works ! :good:

Right now builded the whole OmniROM for my Huawei Ascend P6, and it seems there no issue with your commits !

I'll let you to know how it perform after testing the new build with your improvement !

Thanks again and good luck !

Best regards !
[Android Software/Hacking General [Developers Only]] 95A31:
I have this error:

out/target/product/kumquat/obj/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/libcoregrind-arm-linux.a(m_transtab.o):m_transtab.c:function vgPlain_get_BB_profile: error: undefined reference to 'memmove'
out/target/product/kumquat/obj/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/libcoregrind-arm-linux.a(aspacemgr-linux.o):aspacemgr-linux.c:function split_nsegment_at: error: undefined reference to 'memmove'
out/target/product/kumquat/obj/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/libcoregrind-arm-linux.a(aspacemgr-linux.o):aspacemgr-linux.c:function split_nsegment_at: error: undefined reference to 'memmove'
out/target/product/kumquat/obj/STATIC_LIBRARIES/libcoregrind-arm-linux_intermediates/libcoregrind-arm-linux.a(initimg-linux.o):initimg-linux.c:function vgPlain_ii_create_image: error: undefined reference to 'memmove'
collect2: error: ld returned 1 exit status

Ideas ?
[Android Software/Hacking General [Developers Only]] JustArchi:
Looks like compiler problem.
[Android Software/Hacking General [Developers Only]] Balino:
Your optimizations are just been implemented on my device's cm11 build and whole system is a bit smoother. Keep up the good work!
[Android Software/Hacking General [Developers Only]] 95A31:
Mh.. I use android master branch of GCC 4.8: https://github.com/AndroidOpenSourc...mmit/832e8aee915305d2325bb3c3550e095c59bd0871
[Android Software/Hacking General [Developers Only]] fergy:
[MENTION=5161352]JustArchi[/MENTION]

I was notice that busybox in CM11 (1.22.1) don't want to compile regarding:

external/busybox/android/reboot.c: In function 'reboot_main':
external/busybox/android/reboot.c:44:17: error: 'ANDROID_RB_FLAG_NO_SYNC' undeclared (first use in this function)
external/busybox/android/reboot.c:44:17: note: each undeclared identifier is reported only once for each function it appears in
external/busybox/android/reboot.c:44:43: error: 'ANDROID_RB_FLAG_NO_REMOUNT_RO' undeclared (first use in this function)

...but, that was an minor problem what is simple fixed by inserted:

#define ANDROID_RB_FLAG_NO_SYNC 0x1
#define ANDROID_RB_FLAG_NO_REMOUNT_RO 0x2

inside system/core/include/cutils/android_reboot.h

what is missing inside CM11 (as lot's of other things) except You pick it from cherry, but that will give lot's of other things.... so, manual corrections.

All thing regarding msm7x27a, 7225aa, 7225ab work without any futher problems.

I'll post some test here.