I'm trying to compile using Linaro 6 and I'm receiving this error which I believe have something do do with GCC 6? I'm very amateur with compiling kernels or coding for that matter, but I couldn't figure this out even search similar terms:
CC drivers/iommu/msm_iommu-v1.o
In file included from include/linux/io.h:22:0,
from drivers/iommu/msm_iommu-v1.c:20:
drivers/iommu/msm_iommu-v1.c: In function '__program_context':
drivers/iommu/msm_iommu_hw-v1.h:78:31: warning: result of '16777215 << 14' requires 39 bits to represent, but 'int' only has 32 bits [-Wshift-overflow=]
error, forbidden warning: msm_iommu_hw-v1.h:78
scripts/Makefile.build:308: recipe for target 'drivers/iommu/msm_iommu-v1.o' failed
this is my GitHUB:
https://github.com/mykesorrel/surnia_kernel
Looks like a bug with that iommu driver. It's trying to do a bit-shift into an int instead of a long, an int doesn't have enough bits to complete the operation. I'm guessing the -Wno-error isn't used, so all warnings are treated as errors.
This question will help you: How to compile without warnings being treated as errors?
What I personally do is update CFLAGS in my .bashrc (Assuming you're using Linux). This is what I use:
# Ensure C builds don't fail on warnings
export CFLAGS="-Wno-error"
export CXXFLAGS="-Wno-error"
Related
First time android builder here. I used to do a lot of roll your own back on FreeBSD in the day. Getting back into geekdom with android.
I am trying to build android-7.0.0_r14 for the Nexus 6 NBD90Z to run under emulation. I plan to eventually build for my actual phone and this config is pretty close. I am building on ubuntu 18.04 LTS which is newer than what the docs recommend. Maybe that is a bit adventurous.
Here is what I get when I run make.
... snip
build/core/base_rules.mk:316: warning: ignoring old commands for target
out/target/product/shamu/system/lib/soundfx/libqcomvoiceprocessing.so'
Starting build with ninja
ninja: Entering directory.'
ninja: warning: multiple rules generate out/target/product/shamu/system/etc/gps.conf. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
[ 0% 1/35600] Lex: libaidl-common <= system/tools/aidl/aidl_language_l.ll
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/flex/flex-2.5.39 -oout/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp system/tools/aidl/aidl_language_l.ll"
flex-2.5.39: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
Aborted (core dumped)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
A core dump for flex was not produced in spite of the error message given.
out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp does not exist. That entire folder is empty. It would seem that something is not downloading/copying the aidl_language_l.cpp.
Any ideas on what I might have messed up?
I am still a little confused at the complexity of git/repo/make/ninja/soong/lunch to conduct a build. It is likely that I missed something obvious.
Thanks,
Jason C. Wells
Just replace your make by export LC_ALL=C make or put the export in your .bashrc
After I looked at this a little closer I realized the prebuilt prebuilts/misc/linux-x86/flex/flex-2.5.39 would dump core with no arguments. I created a soft link to /usr/bin/flex. Compilation seems to be proceeding.
I haven't answered why the prebuilt was dumping. My goal is to compile android, not troubleshoot the tools.
I performed Snorky's steps. I deleted my output directory for libaidl-common_intermediates. I deleted my soft link and restored the android tree version of flex. I re-ran make at the top of the local repo. The build proceeded past the error above and stopped at a new error. It appears that Snorky's answer worked.
Doh! I'm new so S.O. didn't give credit for my upvote.
I'm building an armv8a SDK for Android using the NDK and I wanted to build with LTO enabled. I added -flto to the compile and link flags for the C++ toolchain, and all went well, until I tried to run in the emulator, at which point an error like the following was emitted:
WARNING: linker: /data/lib/libservice.so: unused DT entry: type 0x6ffffef6 arg 0x8e30
and
WARNING: linker: /data/lib/libservice.so: unused DT entry: type 0x6ffffef7 arg 0x2fb50
Some research led me to this answer which allowed me to dig out the symbol names for 0x6ffffef6 and 0x6ffffef6, they happen to be TLSDESC_PLT and TLSDESC_GOT respectively, so clearly something to do with dynamic linker and the PLT/GOT, and also with TLS. Fine.
Comparing the non LTO build with the LTO build, these flags definitely only come in for the LTO build:
$ readelf -a /lto/lib/libservice.so | grep TLS
L (link order), O (extra OS processing required), G (group), T (TLS),
TLS 0x000000000001ed70 0x000000000002ed70 0x000000000002ed70
0x000000006ffffef6 (TLSDESC_PLT) 0x8e30
0x000000006ffffef7 (TLSDESC_GOT) 0x2fb50
00000002ffd8 000000000407 R_AARCH64_TLSDESC 0
00000002ffe8 000000000407 R_AARCH64_TLSDESC 8
579: 0000000000000008 8 TLS LOCAL DEFAULT 17 _ZN5xxxxx12_GLOBAL__N_113
788: 0000000000000000 1 TLS LOCAL DEFAULT 17 __tls_guard
$
$ readelf -a /nolto/lib/libservice.so | grep TLS
L (link order), O (extra OS processing required), G (group), T (TLS),
$
So, some questions:
Why does the android armv8a runtime reject these DT flags?
Why does enabling LTO seem to change the TLS implementation or needs? Why do these tags get emitted (along with the other symbols)?
How can I prevent that, or otherwise avoid this issue? Can I request some other TLS model?
I've found at least one other issue like this, where the Android environment rejects the flag DT_ORIGIN which is usually required for $ORIGIN processing, but still honors $ORIGIN even without DT_ORIGIN set. Is the rejection of the TLDESC_ flags potentially a similarly overzealous check, and the code is in fact fine, which would indicate an NDK bug?
Any insights appreciated. Note that this seems to work for other Android targets, specifically the Android x86_64 build worked just fine with -flto, and the resulting binaries do not have any TLSDESC anything in the readelf -a output.
I upgraded to NDK r18 beta2, and I no longer have this problem. It appears that the underlying bug was something to do with not propagating the use of emulated TLS down through the gold linker plugin (see https://github.com/android-ndk/ndk/issues/498), which was fixed in r18.
I use UltimateMobile plugin and uniwebview plugin ,maybe they are conflict.
when I build ,Unity3d console say :
Failed to compile resources with the following parameters:
-bootclasspath
"C:/Program Files/Java/android-sdk-windows\platforms\android-27\android.jar" -d
"C:\Game\3drq\superblocks\Temp\StagingArea\bin\classes"
-source 1.6 -target 1.6 -encoding UTF-8
"android\support\v4\Manifest.java"
"android\support\v4\R.java"
"com\cheerflame\superblocks\Manifest.java"
"com\cheerflame\superblocks\R.java"
"com\google\android\gms\Manifest.java"
"com\google\android\gms\R.java"
"com\google\android\gms\ads\Manifest.java"
"com\google\android\gms\ads\R.java"
"com\google\android\gms\ads\impl\Manifest.java"
"com\google\android\gms\ads\impl\R.java"
"com\google\android\gms\analytics\Manifest.java"
"com\google\android\gms\analytics\R.java"
"com\google\android\gms\appinvite\Manifest.java"
"com\google\android\gms\appinvite\R.java"
"com\google\android\gms\auth\Manifest.java"
"com\google\android\gms\auth\R.java"
"com\google\android\gms\auth\api\Manifest.java"
"com\google\android\gms\auth\api\R.java"
"com\google\android\gms\base\Manifest.java"
"com\google\android\gms\base\R.java"
"com\google\android\gms\drive\Manifest.java"
"com\google\android\gms\drive\R.java"
"com\google\android\gms\games\Manifest.java"
"com\google\android\gms\games\R.java"
"com\google\android\gms\gcm\Manifest.java"
"com\google\android\gms\gcm\R.java"
"com\google\android\gms\iid\Manifest.java"
"com\google\android\gms\iid\R.java"
"com\google\android\gms\plus\Manifest.java"
"com\google\android\gms\plus\R.java"
"com\stansassets\androidnative\Manifest.java"
"com\stansassets\androidnative\R.java"
"com\stansassets\billing\Manifest.java"
"com\stansassets\billing\R.java"
"com\stansassets\googleplay\Manifest.java"
"com\stansassets\googleplay\R.java"
"com\stansassets\mnp\Manifest.java"
"com\stansassets\mnp\R.java"
"com\stansassets\social\Manifest.java"
"com\stansassets\social\R.java"
����: C:\Program Files\Java\android-sdk-windows\platforms\android-27\android.jar(java/lang/Object.class):
���汾 52 �� 51 ��, �˱�����֧�����µ����汾�����������˱�������
����: C:\Program Files\Java\android-sdk-windows\platforms\android-27\android.jar(java/lang/String.class):
���汾 52 �� 51 ��, �˱�����֧�����µ����汾��
���������˱�������
����:
C:\Program Files\Java\android-sdk-windows\platforms\android-27\android.jar(java/lang/AutoCloseable.class):
���汾 52 �� 51 ��, �˱�����֧�����µ����汾��
���������˱�������
3 ������
why there are so many messy code?
I build the project in another computer,it's fine and can be built to a apk file.
I don't understand ,please help me. thanks !
You should downgrade to JDK 8. According to this SO answer which has a similar error message to your question:
As of Unity 2017, Unity is incompatible with JDK 9. You need to
continue to use JDK 1.8 for the time being.
(Note: there is also an active issue on the Unity Issue Tracker for JDK 9 that seems to be related. It's not the exact same error message, but others are commenting there with your error message as well.)
(EDIT: The question's error message shows "android-27", so this may not be the actual solution. I'm leaving this here for now as a solution attempt, and because one of the most common reasons for this error message, in general, is the JDK version.)
(Also, to give one possible explanation for "why there are so many messy code?": the little question mark with the black box has to do with strings and character encodings. It likely has something to do with the asker's computer language being set to another language like Chinese. I'm not sure about the exact cause in this case, but see The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) for more background information about the black box question mark characters:
And in fact now that you’re thinking of things in terms of platonic
ideal letters which are represented by Unicode code points, those
unicode code points can be encoded in any old-school encoding scheme,
too! For example, you could encode the Unicode string for Hello
(U+0048 U+0065 U+006C U+006C U+006F) in ASCII, or the old OEM Greek
Encoding, or the Hebrew ANSI Encoding, or any of several hundred
encodings that have been invented so far, with one catch: some of the
letters might not show up! If there’s no equivalent for the Unicode
code point you’re trying to represent in the encoding you’re trying to
represent it in, you usually get a little question mark: ? or, if
you’re really good, a box. Which did you get? -> �
Ok so first off,
Im brand new to android dev. This is my first attempt at any form of kernel anything. I have a limited knowledge of java and python, but no C.
I have a galaxy tab 4 sm-t330nu running 4.4.2. its running a qualcomm snapdragon 400 msm8226 cpu. im simply trying to do a test build with a vanilla kernel at this point. (also my build environment is the newest kali 1.1 and im loosely following the tutorial at https://github.com/offensive-security/kali-nethunter/wiki/Porting-Nethunter)
so i have all of the required dependencies (i hope), and ive downloaded my source from samsung opensource. unzipped and went through the available defconfigs. after finding "msm8226-sec_milletwifiue_defconfig" i decided it was the most likely candidate for my tablet. (when doing a custom recovery i remember it being "philz touch milletwifiue something)
Ive done my exports (arch= subarch= cross_compile=) and all seems well. When i run a build following exactly as the tutorial says (using the defconfig in their example as a test) i receive an error stating "must define variant_defconfig". So i instead do "make variant_defconfig=msm8974_sec_defconfig" and it builds great.
Now the issue:
When i change "msm8974_sec_defconfig" to my actual msm8226 i receive an error on every build that i cannot seem to workaround. (cut down for size)
CC arch/arm/kernel/armksyms.o
CC arch/arm/kernel/module.o
AS arch/arm/kernel/sleep.o
CC arch/arm/kernel/suspend.o
CC arch/arm/kernel/io.o
arch/arm/kernel/io.c: In function '_memcpy_fromio':
arch/arm/kernel/io.c:14:3: error: implicit declaration of function 'nop' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/kernel/io.o] Error 1
make: *** [arch/arm/kernel] Error 2
My exact bash line reads
make VARIANT_DEFCONFIG=msm8226-sec_milletwifiue_defconfig
Any assistance on clearing this up would be great
edit
although im not familiar with c, it seems to me that '_memcpy_fromio' is where the error lies. and my google searches tell me that the error is that a function is used without being declared. however i dont know if memcpy is a function? or is the function within class memcpy (dont know if c has classes just closest equivalent that i know of) how do i debug this code and declare what needs to be declared (more importantly, if this is a stock kernel thats used by thousands of devices, how can it possibly have an undeclared function?
/edit
found the answer! needed
#import linux/modules.h
#import linux/kernel.h
I am writing a C++ module for the Nexus 7 Android kernel. Previously I compiled this module successfully with the Goldfish kernel. But now after porting the necessary changes to the Nexus 7 kernel, I am getting a compilation error. The problem seems to be with the headers. Whenever i include the linux/fs.h or linux/debugfs.h in the module, it is giving the following error.
/linux/radix-tree.h: In function 'void* radix_tree_deref_slot(void**)':
/android_kernel_grouper-android-tegra3-grouper-3.1-jb-fr2/include/linux/radix-tree.h:153:9: error: 'void*' is not a pointer-to-object type
The corresponding line in the radix-tree.h has something to do with rcu_dereference().
Is the problem with the headers, or the makefile or due to faulty patching?
To find out the compilation parameters used in gcc (or g++), you should use "make V=1" against the makefile. but the error:
error: 'void*' is not a pointer-to-object type
looked more like a C++ error, which is inherent in your code (Android kernel does not use C++).
This seemed to be solvable by recasting:
Error: ‘void*’ is not a pointer-to-object type
C++. Error: void is not a pointer-to-object type
etc.