I'm building git on my Android device in KBOX2 using gcc 4.8 with libcurl, which I also built on device. I'm building with libcurl for http/https support
Configure, make and make install run successfully. However, when I try to clone an https git, I get the following error:
fakechroot: dlopen: undefined symbol: dlopen
I'm aware that fakechroot only intercepts dynamic libc calls. I've dynamically linked all of the supporting libs. What could be causing this error and how do I fix it?
Please let me know what I should post (env vars, configure and/or make options) that would be helpful.
The problem turned out to be rooted in curl...which also threw the same error when performing basic operations.
Short Answer: I scrapped everything...openssl, curl, git...and started over. I made sure that I included -ldl and -lc with all of the builds and I made sure to specify -Wl,--dynamic-linker=/system/bin/linker in the LDFLAGS with all of the builds.
Since I'm still learning about Linux and Android in general and various aspects of configure and make in particular, I'm not sure what fixed the problem. I'll leave this open in case someone with more knowledge wants to chime in.
Related
I'm trying to build an executable from a c file (not written by me) so that I can use it on my phone.
I'm using a toolchain directly from the Android NDK (that use Clang) built for arm64.
The c file needs, as expressed in the makefile, libpthread librtlsdr libmysqlclient, so I downloaded the arm64 versions of these libraries in my toolchain sysroot directory. First question: is this the right way of doing this?
Anyway, after doing this and executing make, it fails saying that it cannot find libpthread.so.0 and libpthread_nonshared.a.
To solve this I copy in the sysroot folder the file it wants from the libc6 arm 64 package (that are not only the two written above, but many others needed in cascade): this way the "make" seems to work fine but once I push it in my device, with the libraries it needs, and run it, I got a runtime error saying:
cannot find verneed/verdef for version index=32770 referenced by symbol "_res" at "/data/local/tmp/TEMP/libc6.so.6"
In this case the problem should be libc6, but I can't figure how to solve this.
This one is related to the libpthread I've downloaded, so the libc6 package, which is probably not suited for Android.
So the real problem is: is there a way to get rid of the first error I mentioned using just the pthread included in Android?
What I hope is that I'm just missing something or using in the wrong way.
Thanks
No, this is not how you are expected to build an executable for Android. You can either use the NDK toolchain, or an alternative toolchain, as described here: Cross compiling static C hello world for Android using arm-linux-gnueabi-gcc.
I've completed the first part of my project, and I want to know how well / bad it performs by profiling it with gprof. I am working on Android using a Linux emulator named Termux, and I am using g++ as the compiler.
Everything compiles without errors and even warnings, and the binary runs perfectly.
So I decided to put the -pg flag among the other flags in my makefile, (meaning that both compilation and linking is performed with -pg) and tried recompiling everything. But something seems to not work properly: during compilation, everything is normal. But when linking I get a argument unused during compilation: '-pg' warning and then a lot of undefined reference to 'mcount' (it doesn't even display all of them, after a bit it says more undefined references to 'mcount' follows) errors, and at the end a linker command failed with exit code 1 error.
What is causing this behaviour? Is something broken / missing on the platform I am using? Can I fix that? How?
Sorry for the short answer, but I'm on mobile. Making a community wiki.
In Termux, g++ is a symlink to clang. -pg is a gnu feature, so does not function when linking using clang.
You could use clang-appropriate techniques for profiling, or install a real g++. One reference is https://android.stackexchange.com/questions/182130/use-gcc-compiler-in-termux but there is also "google performance tools" for profiling out there somewhere.
My problem is the following: I have succesfully built GDAL 1.10.1 using an Android toolchain (CC=i686-linux-android-gcc, CXX=i686-linux-android-c++) that produces the following output libraries libgdal.a, libgdal.la, libgdal.lai, libgdal.so, libgdal.so.1, libgdal.so.1.17.1 in the output folder .libs (in the following I'll call this folder $GDAL_LIB_PATH).
I am trying to build a simple Android app (a simple widget application with a QPushButton named TestAndroid) using Qt 5.4 on Windows. If I don't use GDAL everything works fine and I am able to run my app on an Android emulator for all available platforms: x86, armeabi and armeabi-v7.
Nonetheless, if I try to use GDAL (ex. by simply calling GDALAllRegister() in the initialization of the app) and then linking to libgdal.so the application crashes with the following error:
E/art ( 1614):
dlopen("/data/app/org.qtproject.example.TestAndroid-1/lib/x86/libTestAndroid.so",
RTLD_LAZY) failed: dlopen failed: could not load library
"libgdal.so.1" needed by "libTestAndroid.so"; caused by library
"libgdal.so.1" not found
I have verified that the Android platform is the right one (x86), otherwise the linker would skip the wrong libgdal.so object.
I have included libgdal.so in the *.apk (generated by Qt) using ANDROID_EXTRA_LIBS *= $GDAL_LIB_PATH/libgdal.so. The other files libgdal.so.x.x cannot be included in the same way since Qt prevents it.
In order to avoid dynamic linking I have also tried to link my app with libgdal.a but many link-time errors appears (ex. undefined reference to 'atof')
I have searched on the web but I have not found a solution to my problem.
I am not constrained to use dynamic linking so, a solution to any of the following problems is good for me:
Is there a way to avoid the creation of libgdal.so.x.x files when building GDAL ?
Is there a way to include libgdal.so.x.x files in the *.apk file generated by Qt ?
How can I avoid link-time errors when linking the static library libgdal.a ?
Thanks in advance for any reply!
After several days of trials and errors (mainly errors) I have found a solution to my problem.
I'm writing it as an answer to my question so that it may be helpful to others.
The problem was during the link-time of GDAL. Briefly: the linker created the "real name" shared library libgdal.so.1.17.1 together with the links to it libgdal.so.1 and libgdal.so.
For some reasons (which I ignore) forcing the link to libgdal.so, the linker searches for libgdal.so.1 (which, in turn, would have searched for libgdal.so.1.17.1).
The workaround that solved my problem can be summarized in the following steps:
In the GDAL root, run the ./configure according to the desired configuration (see http://trac.osgeo.org/gdal/wiki/BuildingForAndroid) checking that libtool is ENABLED
Edit the created libtool file (e. g. with gedit) as follows:
replace the value of library_names_spec with library_names_spec="\$libname\${shared_ext}"
replace the value of soname_spec with soname_spec=""
Type make
In the output folder .libs/ the only libgdal.so will be created and now the link to libgdal.so seems to work fine.
I've got a hold of a proprietary JNI application which I need to build for a MIPS device. I've read "Initializing a Build Environment", parts of the NDK docs, some Google Groups threads and numerous StackOverflow questions, but I'm still short of my answer.
So far, I've checked out the Android source using Google's repo script and have it under ~/AndroidSource. I've also separately downloaded the SDK under ~/AndroidSDK and the NDK under ~/AndroidNDK. The code I'm trying to build is in a separate location. The SDK and NDK binaries are in my path. For building, I tried to use two different versions of the NDK as well as the one under the Android source tree, and experienced different sets of problems. My current setup uses NDK r8b, downloaded separately from the Android source.
The application has its Android.mk and jni/Android.mk. However, several directives in the latter point to paths such as
frameworks/base/include
system/core/include
with no prefixes. I thought these were meant to point to the respective directories in the Android source, so I symlinked them to the current directory. After some more symlinking and makefile and source hacking, I got the application to compile, but am currently stuck on the linking phase with lots of references to missing method bodies. During the whole time I knew I was doing something wrong.
I'm on a Linux x86_64 host, if it is of any concern.
So my question is:
What is the proper method to set up a build environment for JNI applications? What environment variables, symlinks and/or path expansions should I set up? Do I need to call any scripts once or before each ndk-build invocation?
Also, I'd be happy if you corrected me on any concepts or terminology I've gotten wrong.
Your approach wiyh symlinking the AOSP tree for system headers is correct. What you need now are the system libraries compiled for MIPS. The easiest way to get them is to adb pull them from a target device (or emulator image). But you can also build these libraries yourself, as part of the AOSP build (see build instructions for the source tree you downloaded).
If you still have any problems remaining, run your ndk-build with parameter V=1 and publish the link command and its results.
I use the following in my build (YMMV).
Explicitly invoke arm-linux-androideabi-gcc as your compiler or linker (should be in PATH).
NDK_PLATFORM=/path/to/android-ndk-r*/platforms/android-14
Pass -I"$(NDK_PLATFORM)/arch-arm/usr/include" to the compiler
Pass -nostdlib -L"$(NDK_PLATFORM)/arch-arm/usr/lib/" -lgcc -lc -lm to the linker
I recently developed a project in C which makes use of the function clock_gettime() in linux. The linking for this on my Ubuntu desktop is achieved using the linker flag:
gcc -lrt foo.c
I was excited to read that I could cross-compile my project for the Android in the post below.
http://benno.id.au/blog/2007/11/13/android-native-apps
I've tried this on trivial projects though using the command:
arm-linux-gnueabi-gcc -static foo.c -o foo
Rather than the command:
arm-none-linux-gnueabi-gcc -static foo.c -o foo
referred to in the link, and they do indeed compile and link fine, but when I try with my project requiring clock_gettime() and the linking:
-ltr
It fails with:
undefined reference to `clock_gettime'
I've read that library specified by -lrt doesn't exist for the Android, and I've found posts other places claiming that folks are using clock_gettime() on Android projects, but I haven't been able to find the right library to link to for this. Can anyone tell me what I need to link to for the ARM to make this work?
Or make any other suggestions as to alternatives that will work on the Android.
I am very much interested in leveraging my existing makefiles from my Desktop linux projects to what extent I can, but reconfiguring them to work with the cross-compile tool chain if possible, so any suggestions which would allow for that would be very greatly appreciated.
Android's "bionic" C library has a wrapper for the clock_gettime() syscall. If you build using the Android NDK you'll get that automatically. Otherwise you need to add a bionic library to your toolchain somehow.
Alternatively, you could call the syscall directly via assembly (from memory, the first argument goes in R0, the second in R1, you put the syscall number in R7, issue "SWI $0" and find the result code in R0).
Alternatively: why are you bothering with clock_gettime? Is there any reason you can't simply use gettimeofday()?