I need to compile libmysqlclient and librtlstr for Android (in fact I could find rtlsdr, but since I need mysqlclient the issue is still there).
I followed several guides but most of them present the instruction written here http://mortoray.com/2012/08/21/android-ndk-cross-compile-setup-libpng-and-freetype/
Anyway, the package I download did not contain any configure file so I don't know how to continue.
Because the purpose of this file should only be the creation of the makefile, maybe there is a way solve this.
So my questions are:
1) Is this the right approach? Are there others easier?
2) Does a general configure file exist so that I can download and use it?
3)If not, how does the makefile has to be written? This way I should be able to overcome the abscence of configure file
I need those libraries to port a c code (which needs them) to android building an executable that I'll run on my phone (so I already have the standalone toolchain from the NDK), if it helps
1) This is right approach (may be a little bit simplified, I'm using more steps to build) for libraries, which use automake. Much easier, if library uses Cmake (must contain CMakeLists.txt), because you need only NDK. Example: cmake -DANDROID_NDK=path/to/ndk -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=armeabi-v7a -DANDROID_PLATFORM=android-21 ..
2) No, also you need provide additional files (for example, Makefile.in)
3) This libraries have to use one of tools such CMake, automake etc, just Makefile or project for some IDE. So, try to find out, what of this use your libraries
Related
I would like to use a shared library, that is compiled for arm64, on Android. I have my .so file inside a aarch64-linux-gnu folder, but for other libraries I have instead a aarch64-linux-android folder.
Please can these libraries compiled for aarch64-linux-gnu run on an arm64 Android device? What do these names stand for precisely? I know that aarch64 refers to the arm64 processor architecture but I don't know how the operating system is related here.
Thank you!
Android and ARM my have some libraries that are the same. Basically the SO file has to be able to find all the libraries it was linked against to run, and the versions need to match up so nothing breaks. This is risky, and it is generally safest to compile the entire program on your target machine. You can see if everything can be located/what is missing using:
ldd /path/to/file.so
this will give you a list of libraries and where the file thinks they are - or ??? if it can't find it. You need to double check and see if the results of this look OK.
Even if all dependencies are found, mismatch in versions or architecture will cause the program to break at run-time. You need to extensively test the use of the externally linked library and even then you may miss some cases that break your program. For this reason I would try and get the source code if possible, and re-compile everything on the target machine.
I'm trying to cross-compile the qhull library for Android, on a Linux x86-64 host. I'm fairly new to CMake, but rather experienced with other buildsystem tools.
I've setup a toolchain file, according to all the recommendations I've found, and it has worked for several other packages. Yet, no matter what I try, nothing seems to augment the linker path for one or more of qhull's executable programs. The problem is that it can't find Android NDK's libsup++.a, which is an implicit dependency of its compiler (GCC). If I take the generated link command and manually add -Lpath_to_libsup++.a, then the link succeeds.
In my toolchain file, among the things I've tried are:
CMAKE_FIND_ROOT_PATH
link_directories()
CMAKE_EXE_LINKER_FLAGS
I don't see anything unusual about its CMakeLists.txt, at least with respect to the first point of failure (user_eg3).
I'd prefer not to patch the library, if possible. I know many others are using this on Android (it's a dependency of point cloud library), so I assume I'm probably missing a step.
BTW, I'm using CMake v3.4.3, Android NDK r10e, and qhull v7.2.0.
I found a workaround.
In this post, Florian mentioned that CMake internally sets CMAKE_EXE_LINKER_FLAGS_INIT to $ENV{LDFLAGS}. I've found that if I set the environment variable LDFLAGS=-Lpath_to_libsup++.a, it gets passed through to the link command, which now succeeds.
I'd still like to know the proper CMake solution to this problem. Or, if the problem lies with qhull, then maybe someone can peek at its CMakeLists.txt (linked above) and point out what it's doing wrong.
I want to use some function calls(commands) designed for linux. I can use them by enter the key words in adb(Android CML).
Here I found some works some people did.
wget (because it isn't included in most Android device )
Iperf
But after reading their methods or suggestions, I can only understand that I need to use Android NDK and write the correct makefile. I have no idea about building others source code (most of them are C/C++) for linux(only need to use 'make' command mentioned in their README file). The official NDK document is for Java environment to call C lib mainly.
Are there some HOWTO, courses or suggestions for this. Thanks!
I have compiled single cpp file program. I try to compile a alternative version iperf
https://github.com/tierney/iperf
It seems to be relative to lib ,some header files, and multiple c files. I failed to compile by enter all c files normally. Is there anything I missed?
yeah you need the NDK, it offers an C/C++ compiler for Android.
In general the steps are all the same:
Setting up the NDK (I wrote a small how-to, but it's for Arch-Linux and the fish-shell, Windows how-to)
Adjusting your make file (instead of gcc compiler use Android NDK compiler, and so on)
Remember that Android uses Bionic C library, so only use functions supported by it
Run make, push the program to your device and make it executable
Of course, this is just an overview how it is done. You should try it and then ask specific questions if you run into troubles.
NDK is mostly intended to extend the Java apps, but you can download NDK and create a standalone toolchain from it (see http://www.kandroid.org/ndk/docs/STANDALONE-TOOLCHAIN.html). Now you have a cross-compilation environment which is very similar to standard Linux dev environment.
In addition, for small executables and for testing only, you can also cross-compile and link statically to the libc. This way you don't have to worry about Bionic which could be a loss of time.
Can somebody help me write Android.mk for LibXtract or point me in correct directoin?
Here is source for lib - https://github.com/jamiebullock/LibXtract.git
Or mayby there is a way to use linux generated shared objects in Android?
Especially for bigger established projects, crafting Android.mk files is quite an effort. More so, if you are not familiar with Android NDK build architecture whose understanding requires digging deep into the documentation and Android NDK make files. I would suggest trying to use existing make files by setting CC to point to your NDK tool chain, and CFLAGS += -sysroot $(SYSROOT) where SYSROOT=${NDK_INSTALL_DIR}/platforms/android-<level>/arch-<arch>/ (depending on targeted Android API version and architecture). Even without knowing about your library, I would bet you should have good chance of success this way. Android NDK documentation (${NDK_INSTALL_DIR}/doc/STANDALONE-TOOLCHAIN.html) details the use of independent tool chain and also instructs how to create a standalone tool chain that will not require the use of -sysroot argument to xxx-gcc.
If you decide to use Android.mk instead, you might check existing projects -CSipSimple comes to my mind (PJSIP converted from standard form GNU make files).
Important is to create the shared objects using Android tool chains. It is possible to build them outside of your application source tree, and then just copy the shared objects into the package source libs/<architecture>/ directory.
Integration with your build system depends on details that are not known (including how smooth you desire this whole integration to be e.g. because of other people working with the same project). If you are creating an application from command line, the easiest would be to have GNU make file or shell script in the package root directory ensure libXtract.so and your application package is up-to-date by calling libXtract make file and ant to build and pack your Java application. If you are using ant there should be a way to specify using make to take care of libXtract.so. I am not sure if eclipse is completely relying on ant for building an application to know if this would be enough for enabling complete build by clicking mouse buttons from within eclipse, too.
The answer to this question says you could use cmake script to build Android.mk files - I have not tried this approach.
I am interested in integrating Scala (or some other non-Java JVM-language) into the android platform. I am not referring to writing an android application with Scala, that I did early early on, but actually hooking into the build process that builds the android platform source tree. I imagine this will be a matter of hooking into the makefiles and such. Does anyone have insight into this?
What I have so far:
The platform source treefrom git://android.git.kernel.org/platform/manifest.git built in its virgin form, guided by "[Download and build the Google Android][1]"
build/core/combo/scalac.mk # Configures scala compiler related variables, included by config.mk
Added definitions in build/core/definitions.mk for an all-subdir-scala-files and an all-scala-files-under
Added definition in definitions.mk to build scala files such that they are included in the package
What's left:
Include scala-library.jar
Ensure changes to -bootclasspath has not broken anything
Figure out how to handle case where scala classes depend on java classes and visa versa
Major cleanup of code
Testing!
Figure out what to do (other than just posting them here) with the changes I've made
Looks like I'm almost there!!!
Some notes from the past
Latest: I have found where the Java source files are compiled! In definitions.mk, see 'define transform-java-to-classes.jar'. The latest idea is to write a transform-scala-to-classes definition and then have it store those classes in the directly that gets packaged. I will call transform-scala-to-class right before this step in transform-java-to-classes.jar. Support for eclipse and cygwin will for now be dropped as it clutters up the code with workarounds and therefore increases my chances of failure.
The build process starts out by the root Makefile running build/core/main.mk
build/core/main.mk includes build/core/config.mk which includes build/core/combo/javac.mk which sets HOST_JAVAC, TARGET_JAVAC, and COMMON_JAVAC. COMMON_JAVAC is the "Java compiler command with common arguments," by the look of it the other two variables get these values by default, unless in a special environment (openjdk or eclipse). COMMON_JAVAC is not used outside this file. The other two are only used in build/core/definitions.mk.
build/core/java_library.mk (included by config.mk) seems to only be concerned with building jars. This is out of the scope of us caring. Any interaction with jars presupposes class files which presuppose that we were already successful in building our scala files.
There are checks in main.mk regarding the version of java. We will ignore these and assume that our version of scala is compatible. Right now (in combo/scalac.mk) I am using the same --target arg used in javac.mk. This should perhaps be stored in a variable.
main.mk also includes build/core/definitions.mk which in turns defines some useful functions. The one we care about here is all-java-files-under and all-subdir-java-files. The latter is used in Android.mk files to find java files. The former is used in the implementation of the latter. I will write Scala equivalents of them.
To figure out how the build process works, I am now running make with -n and others. I got this idea from the stackoverflow article "[Tool for debugging makefiles][2]". I am also investigating debugging with remake.
build/core/{config.mk, definitions.mk} gives us light as to which make files/commands are used to do what.
As a possible way of hacking in support on a per project bases, additional code could most likely be added to the project's Android.mk file. From platform/build/core/build-system.html we read "Android.mk is the standard name for the makefile fragments that control the building of a given module. Only the top directory should have a file named "Makefile"." You could create a new target like "scala-build" and run that (make PackageName scala-build) before the final make. One could perhaps also hide it sneakily in a variable assignment, mitigating the need for a target to be called explicitly.
Another way (far far more hackish) is to hijack the command being used for javac. This is set in build/core/combo/javac.mk. Your project's Android.mk will have to include *.scala files in LOCAL_SRC_FILES along with the *.java files.
Guys on reddit say, there's a tutorial on integration Scala into Android with ant here.