I followed this page https://developer.android.com/ndk/guides/ to install the necessary to getting started.
So I open new project as I do normally with checking c/c++ and blank example.
when android studio open the main window, it can't build the default program by giving this error :
External Native Build issues (2 errors).
this is the contents of the file CMakeOutput.log :
The target system is: Android - 1 - armv7-a The host system is: Linux
- 4.17.6-1-ARCH - x86_64
and this is the contents of the file CMakeError.log :
Determining if the C compiler works failed with the following output:
Change Dir:
/home/abdelillah/AndroidStudioProjects/test/app/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp
Run Build
Command:"/home/abdelillah/Android/Sdk/cmake/3.6.4111459/bin/ninja"
"cmTC_dd920" [1/2] Building C object
CMakeFiles/cmTC_dd920.dir/testCCompiler.c.o FAILED:
/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang
--target=armv7-none-linux-androideabi --gcc-toolchain=/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64
--sysroot=/home/abdelillah/Android/Sdk/ndk-bundle/sysroot -isystem /home/abdelillah/Android/Sdk/ndk-bundle/sysroot/usr/include/arm-linux-androideabi
-D__ANDROID_API__=15 -g -DANDROID -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -mthumb -Wa,--noexecstack -Wformat -Werror=format-security -o CMakeFiles/cmTC_dd920.dir/testCCompiler.c.o -c /home/abdelillah/AndroidStudioProjects/test/app/.externalNativeBuild/cmake/debug/armeabi-v7a/CMakeFiles/CMakeTmp/testCCompiler.c
/home/abdelillah/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/clang:
error while loading shared libraries: libtinfo.so.5: cannot open
shared object file: No such file or directory ninja: build stopped:
subcommand faile
other things, I can't edit "native-lib.cpp" directly in the main window, because it's not appear in the folder cpp in the left side even this file exist, I can see it using terminal. the following image show you what I mean
IMAGE
I need help
This was an issue with some NDK binaries before r18: https://github.com/android-ndk/ndk/issues/574
r18 is unfortunately still in beta at time of writing, so it's not really a solution to your problem yet. You might be able to install specifically ncurses 5 on your system which should fix the problem, otherwise your best bet is to use a docker image or a VM based on Ubuntu for the time being.
Note that, in general, best compatibility for Android tools is going to be on Ubuntu/Debian. We fix issues for other distros when we can, but they are not actively tested to my knowledge.
Related
I'm using Android Studio to build an app containing a module that uses the NDK. There is evidence of memory corruption so I'm trying the Address Sanitizer, following these instructions on the NDK developer site. But the app won't build.
I need to (A) ensure I'm targeting Android 27+ (I set minSdkVersion to 27; I'm building a debug build for a Galaxy S9, SDK 28), and (B) add compiler flags, which I've done:
android {
defaultConfig {
externalNativeBuild {
cmake {
# Can also use system or none as ANDROID_STL.
arguments "-DANDROID_ARM_MODE=arm", "-DANDROID_STL=c++_shared"
cppFlags "-fsanitize=address -fno-omit-frame-pointer"
}
}
}
}
I've also added wrap.sh scripts according to the instructions but I understand that they become relevant only at runtime.
The problem is that my app won't build. The output follows.
The C++ compiler
"C:/Users/user/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir:
C:/Users/user/studio/app/android/audioengine/.externalNativeBuild/cmake/debug/arm64-v8a/CMakeFiles/CMakeTmp
Run Build
Command:"C:\Users\user\AppData\Local\Android\sdk\cmake\3.6.4111459\bin\ninja.exe"
"cmTC_58655"
[1/2] Building CXX object
CMakeFiles/cmTC_58655.dir/testCXXCompiler.cxx.o
[2/2] Linking CXX executable cmTC_58655
FAILED: cmd.exe /C "cd . &&
C:\Users\user\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe
--target=aarch64-none-linux-android27 --gcc-toolchain=C:/Users/user/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64
--sysroot=C:/Users/user/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/sysroot
-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++ -fsanitize=address -fno-omit-frame-pointer -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--gc-sections CMakeFiles/cmTC_58655.dir/testCXXCompiler.cxx.o -o cmTC_58655 -latomic -lm && cd ."
C:/Users/user/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin\ld:
warning: liblog.so, needed by
C:\Users\tim\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\lib64\clang\8.0.2\lib\linux\libclang_rt.asan-aarch64-android.so,
not found (try using -rpath or -rpath-link)
clang++.exe: error: linker command failed with exit code 1 (use -v
to see invocation)
The compiler flags have been passed correctly. There is a warning concerning liblog.so not being found, but then a non-specific error.
The instructions show where to place the sanitizer libraries in the project (in the jniLibs folder), but not where to source them. I copied them from the NDK install on my machine. I tried doing the same with liblog libraries but It's not clear which variant to use; the one I tried (for SDK 28) didn't affect the result.
What am I missing? I've found posts struggling with understanding exactly how to use the address sanitizer, but none mentions this particular problem.
Looks like those docs are wrong. It seems that CMake isn't using all of the linker flags it needs when performing that test. I'm not sure if that's NDK bug or a CMake bug, but here's a way to make ASan work with CMake/gradle:
Remove the cppFlags section from your build.gradle
Add those options in your CMakeLists.txt instead, like so:
add_library(app SHARED app.cpp)
target_compile_options(app PUBLIC -fsanitize=address -fno-omit-frame-pointer)
set_target_properties(app PROPERTIES LINK_FLAGS -fsanitize=address)
I've uploaded a change to fix the docs. Should be live soon.
This is a most vexing issue. When I run my makefile I see two sysroot in the output:
ubuntu#ubuntu:~/Desktop/LatestAndroidstuff/CmE_source_DAL_1.7_3564/CmCompact$ make
platform/wince/WibuCmHID/rules.mak:31: WibuCmHID only for Windows CE
/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc -I./ -I./external/hidapi/include -Os -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm -o obj/release/android/armeabi-v7a/static/w_refcount.o -c base/w_refcount.c
In file included from base/w_refcount.c:29:0:
./base/w_define.h:31:19: fatal error: stdio.h: No such file or directory
#include <stdio.h>
^
compilation terminated.
rules.mak:54: recipe for target 'obj/release/android/armeabi-v7a/static/w_refcount.o' failed
make: *** [obj/release/android/armeabi-v7a/static/w_refcount.o] Error 1
If I edit the failing command and remove the extra sysroot (the second one), it works.
/home/ubuntu/my-android-toolchain/bin//arm-linux-androideabi-gcc -I./ -I./external/hidapi/include -Os -std=c99 -Wall -Wextra -fno-short-enums -fno-strict-aliasing --sysroot=/home/ubuntu/my-android-toolchain/sysroot --sysroot=/home/ubuntu/android-ndk-r13b/platforms/android-14/arch-arm -o obj/release/android/armeabi-v7a/static/w_refcount.o -c base/w_refcount.c
Problem is, I have looked all over the makefile. The makefile is simple enough:
WBSMAK_ANDROID_NDK_HOME=/home/ubuntu/android-ndk-r13b
SYSROOT=/home/ubuntu/my-android-toolchain/sysroot
ANDROID_TOOLCHAIN_DIR=/home/ubuntu/my-android-toolchain/bin/
WBSMAK_ANDROID_CC=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-gcc
WBSMAK_ANDROID_LD=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ld
WBSMAK_ANDROID_AR=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ar
WBSMAK_ANDROID_RANLIB=${ANDROID_TOOLCHAIN_DIR}/arm-linux-androideabi-ranlib
SHELL := /bin/bash
AR := WBSMAK_ANDROID_AR
CC ?= WBSMAK_ANDROID_CC
LD ?= WBSMAK_ANDROID_LD
RANLIB := WBSMAK_ANDROID_RANLIB
In order to make the file pick up sysroot:
CFLAGS_ARCH := --sysroot=${SYSROOT}
But there is no mention at all in the makefile about that other second sysroot nor that path that shows up. Also, I looked and made sure it's not picking up an environment variable.
ubuntu#ubuntu:~/my-android-toolchain$ printenv | grep SYSROOT
ANDROID_SYSROOT=
LINARO_SYSROOT=/home/ubuntu/linaro-toolchain-4.6/arm-unknown-linux-gnueabi/sysroot
SYSROOT=/home/ubuntu/my-android-toolchain/
The environment sysroot it pointed to where I want it.
If I move the Android NDK folder and all its stuff out of the path, that is nowhere in the makefile, then I get the error. If I have the folder where the extra sysroot is, then the library compiles and links, but it crashes on the Android device, which is Android 21, not 14. I don't know why it's always Android 14. Could I be missing some setting somewhere? Perhaps when I created the standalone tools using make-standalone-toolchain.sh something hardcoded went in so the calls to /home/ubuntu/my-android-toolchain/bin/arm-linux-androideabi-gcc always searches for the android-14 path?
Very vexing problem. I have been all over the makefile. I don't know why the gcc keeps picking up that android 14 sysroot. Could I be only providing for the compilation but the linking is pulling up a default sysroot?
Alright the issue appears to have been a carefully sidelines .mak file in a subfolder that was looking for a string in a string of an existing field and on finding that, was using ANDROID_ARCH for the --sysroot in the actual gcc call. But to the credit of who wrote it, it did have the other -march setting needed for proper compile and linking of the android native module.
Moral of the story: always surf around the folders and take a glance at everything.
(of course my app still crashes but that's another matter to find that out... )
I use Asus router (based on ARMv7 proc) with Advanced Tomato installed
on it as my ARMv7 developer platform. I install compiler (gcc - 5.4.0-1)
plus dependencies and libFTDI (libftdi1 - 1.3-1) from OpenWRT Linux
repo. OpenWRT does not provide libftdi-dev so I copied ftdi.h file from libFTDI download page to /opt/include directly. I try to compile program taken directly from libFTDI samples. The
compiler command is:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9-fno-caller-saves -mfloat-abi=soft -l ftdi1 d.c -o d
But compilation fails because:
/opt/bin/ld: cannot find -lftdi1
But there is /opt/usr/local/lib/libftdi1.so linked to libftdi1.so.2
My LD_LIBRARY_PATH looks like this:
/lib:/usr/lib:/usr/local/lib:/opt/lib:/opt/usr/lib:/opt/include:/opt/usr/local/lib:/opt/usr/include
So what the problem is?
I dont know why (probably bug) but for compiler taken from OpenWRT repo, MUST have wanted library in /opt/lib. So simply copy libftdi1.so.2.3.0 file and linking it to libftdi1.so resolved problem. That means that it does not use correctly LD_LIBRARY_PATH variable. Finally compilation command looks like this:
gcc -v -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -l ftdi1 arco.c -o arco
From my point of view - topic closed
I have a problem with installation of pyhunspell bindings for hunspell library in python 3.2 virtualenv. I downloaded hunspell from here. I issued ./configure and make and it run all right. I avoided however to do make install because my purpose is to install it on virtualenv on a web server, where I have no root permissions.
Thus I downloaded pyhunspell bindings and unzipped it to the directory, where hunspell is made. I modified include_dir path in setup.py by adding correct destination and applied the patch which allows to build pyhunspell with Python 3. Then I ran python setup.py install (having activated the target virtualenv before), but I got this:
$ python setupy.py install
running install
running build
running build_ext
building 'hunspell' extension
gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -fPIC -D_LINUX -I./src/hunspell -I/usr/include/hunspell -I/usr/include/python3.2mu -c hunspell.c -o build/temp.linux-x86_64-3.2/hunspell.o -Wall
creating build/lib.linux-x86_64-3.2
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-x86_64-3.2/hunspell.o -lhunspell-1.2 -o build/lib.linux-x86_64-3.2/hunspell.cpython-32mu.so
/usr/bin/ld: cannot find -lhunspell-1.2
collect2: error: ld returned 1 exit status
error: command 'gcc' failed with exit status 1
It seems that linker cannot link something because it looks for it in system path, while I didn't install the library in the system. Can someone wiser than me in the arcana of C devise any workaround to this issue?
I'll add that I have no access to the real server yet, but I know it will have the system pretty much similar to my local one (Debian 7.0 Wheezy), so I decided to give it a try before I actually log in to the server. Is it possible that the library compiled on my computer would work also on the server, assuming it would also be some (stable probably) version of Debian?
There's no need to build Hunspell. Install the Wheezy packages libhunspell-1.3-0 and libhunspell-dev. It should work with HunSpell 1.3. Just modify setup.py to use libraries = ['hunspell'].
FYI, the posted patch has a problem. It adds the methods of HunSpell as module functions. These receive the module as the first argument instead of the expected HunSpell instance. For example, if you call hunspell.spell, the process will probably segfault when it tries to use self->handle. You should fix the PyModuleDef to get rid of these mal-functions. Change line 273 of hunspell.c to use NULL instead of HunSpell_methods.
how to cross compile zthread for ios 5.1 , any one can help me ?
http://www.cnblogs.com/maadiah/archive/2012/04/06/2434591.html
and
http://www.haogongju.net/art/1382733
i try the links way , but fail with this error.
./configure --prefix=/usr/local/iphone --build=arm-apple-darwin10 --enable-static=yes --enable-shared=no CC=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc CFLAGS="-arch armv7 -pipe -mdynamic-no-pic -std=c99 -Wno-trigraphs -fpascal-strings -O2 -Wreturn-type -Wunused-variable -fmessage-length=0 -fvisibility=hidden -miphoneos-version-min=3.2 -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/usr/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk" CPP=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/arm-apple-darwin10-llvm-g++-4.2 AR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ar LDFLAGS="-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk -miphoneos-version-min=3.2"
got the errorlog :
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
llvm-g++-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/arm-apple-darwin11-llvm-g++-4.2': execvp: No such file or directory
configure:2222: error: C++ compiler cannot create executables
all log is :
I also experienced this error for another project. It's because now Xcode 4.3 became an app installed in the /Applications folder (and no more under /Developer) and all paths changed.
First: did you install the Xcode Command-Line tools? You can verify it opening the menu "XCode-->Preferences-->Downloads".
After having installed them, you should find all the compiler commands under:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/bin/