Android Compilation
Moderator: Moderator Team
Android Compilation
I'm looking for a way to cross-compile DCMTK with R13B (latest) for a variety of architectures. My current problem is the emulator. It fails to launch, doesn't even seem to try.
The question is, can you build just the libraries and skip the unit tests? Seems a reasonable path, but I'm still digging through CMake scripts to find out.
The question is, can you build just the libraries and skip the unit tests? Seems a reasonable path, but I'm still digging through CMake scripts to find out.
-
- DCMTK Developer
- Posts: 2517
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Android Compilation
I don't know what "R13B" is but if you use GNU Autoconf (aka "./configure") calling "make libsrc-all" in the main DCMTK directory should do the job.
Ah I see, you've explicitly mentioned CMake ... at least there is a way to disable building the command line tools in the "apps" subfolder. Just set "BUILD_APPS" to "OFF".
Ah I see, you've explicitly mentioned CMake ... at least there is a way to disable building the command line tools in the "apps" subfolder. Just set "BUILD_APPS" to "OFF".
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: Android Compilation
It is not just the unit tests that depend on the emulator though. There are currently two configuration checks that are run using the emulator to query the properties of the fundamental arithmetic types on the target architecture and whether char is signed or unsigned by default. You could of course guess the results of thoses tests, but this would still require modifying our current CMake setup. I would recommend correctly setting up the emulator instead, though, you are probably using Windows and I very well remember what that was like (the NDK+Toolchain are fundamentally UNIX like, so on e.g. Linux it just works, on Windows it's a configuration hell).
Re: Android Compilation
R13b is the latest version of the Android NDK toolchain. We have a version compiled for R9d but it is causing problems because it is so old and holding back the project generally.
Re: Android Compilation
Using macOS. In the toolchain you know your target architecture, but you're saying that you're probing the emulator for type information? Don't you have that already based upon the target of the toolchain?Jan Schlamelcher wrote:It is not just the unit tests that depend on the emulator though. There are currently two configuration checks that are run using the emulator to query the properties of the fundamental arithmetic types on the target architecture and whether char is signed or unsigned by default. You could of course guess the results of thoses tests, but this would still require modifying our current CMake setup. I would recommend correctly setting up the emulator instead, though, you are probably using Windows and I very well remember what that was like (the NDK+Toolchain are fundamentally UNIX like, so on e.g. Linux it just works, on Windows it's a configuration hell).
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: Android Compilation
Interesting. I would expect that to work like on Linux, never tested it though. I will ask one of our student associates who is also using a mac for help.palmerc wrote:Using macOS.
As far as I know not in general. The results may depend on other things like what standard library is linked or Android ABI version. Both tests I mentioned are used on all platforms, so I 'simply' created a workaround using the emulator regarding Android (and Wine for Cross-Compiling from Linux->Windows). If you know a better way, feel free to tell us or at best send in a patch.palmerc wrote:In the toolchain you know your target architecture, but you're saying that you're probing the emulator for type information? Don't you have that already based upon the target of the toolchain?
Re: Android Compilation
While the specifics as to why you need to test for char signedness might go beyond some simple solution one easy fix for gcc and clang is to choose. -fsigned-char or -funsigned-char. In the case of the Android NDK you can rely on the fact that this will work. FYI ARM is unsigned by default.
The reason this is important is because compiling NDK projects should be a matter of defining
externalNativeBuild {
cmake {
path "src/main/jni/CMakeLists.txt"
}
}
in gradle and let it rip through all the different ABIs you care about.
Another small item, that android.toolchain.cmake file is pretty crusty. You can eliminate it entirely if you support externalNativeBuild in the 2.2.x+ build tools.
The reason this is important is because compiling NDK projects should be a matter of defining
externalNativeBuild {
cmake {
path "src/main/jni/CMakeLists.txt"
}
}
in gradle and let it rip through all the different ABIs you care about.
Another small item, that android.toolchain.cmake file is pretty crusty. You can eliminate it entirely if you support externalNativeBuild in the 2.2.x+ build tools.
Re: Android Compilation
I've been working on getting this to compile on Linux (Ubuntu) since macOS seems to present issues. Couple of issues that would be nice to get a comment on...
The CMake script is looking for the /cache directory to move files to/from in the compilation process. This is an issue since the script continues after 'wait-for-device' completes, but doesn't wait for boot to complete. The filesystem at this point is read-only not read-write so the 'magic' of the script is failing and I'm attempting to debug it and come up with a plan of action.
I'll probably need remount the filesystem since I assume Android always boots with rootfs as read-only,, but this seems a major oversight and makes me wonder if I'm missing something or if the script doesn't reflect recent changes in the Android SDK tools. Another tack would be to use the /sdcard, but again I believe this will need to be fully booted before attempting to upload files.
Does anyone actually have this working? Maybe provide some detail as to the environment in which cross-compile is successful?
The CMake script is looking for the /cache directory to move files to/from in the compilation process. This is an issue since the script continues after 'wait-for-device' completes, but doesn't wait for boot to complete. The filesystem at this point is read-only not read-write so the 'magic' of the script is failing and I'm attempting to debug it and come up with a plan of action.
I'll probably need remount the filesystem since I assume Android always boots with rootfs as read-only,
Code: Select all
adb shell mount -o rw,remount rootfs
Does anyone actually have this working? Maybe provide some detail as to the environment in which cross-compile is successful?
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: Android Compilation
I guess this would be the thing, I created the respective functionality in Q4 2014/Q1 2015 and did not touch it since then. We should collect the issues that appear with newer NDKs/SDKs so I can add it to our bug tracker. I'll have a look at it myself as fast as I can, but I am pretty occupied with other tasks at the moment, so creating a bug tracker entry is probably all I could handle for now.palmerc wrote:if the script doesn't reflect recent changes in the Android SDK tools
Re: Android Compilation
I have managed to get past the emulator issue.
Required (in my case) -
Now I have to work pass compilation problems. I'll test and see if it is clang that is the issue by forcing gcc.
Required (in my case) -
- Waiting for adb shell getprop sys.boot_completed == 1
adb shell -o rw,remount rootfs
adb shell mkdir /cache
Now I have to work pass compilation problems. I'll test and see if it is clang that is the issue by forcing gcc.
Re: Android Compilation
I see the issue...
It seems we're getting hung up on getpwnam_r and getlogin_r not being available in pwd.h.
I just deleted the getpwnam and getlogin calls and everything compiles.
If you want I can clean this up and try to create a pull request for you.
It seems we're getting hung up on getpwnam_r and getlogin_r not being available in pwd.h.
I just deleted the getpwnam and getlogin calls and everything compiles.
If you want I can clean this up and try to create a pull request for you.
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: Android Compilation
Sure, it would be great if you created a patch and sent it to us via email. I would then create an entry in the bugtracker and attach the patch for everyone else, or, if it's straightforward, just commit it.palmerc wrote:If you want I can clean this up and try to create a pull request for you.
Re: Android Compilation
The script makes a large number of checks using CHECK_FUNCTION_EXISTS, but according to the documentation:
I think you want to use CHECK_SYMBOL_EXISTS. I changed it for getlogin, getpwnam, getpwnam_r and it cleared up the compile issue. It needs to be tested more generally, obviously.This does not verify that any system header file declares the function, only that it can be found at link time (consider using CheckSymbolExists).
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: Android Compilation
I'm also not sure about that, as we often have #ifdef code that declares some functions exactly in that case, so perhaps we just need to add || defined(_ANDROID_) some times. The best solution would (obviously) be to run both CHECK_FUNCTION_EXISTS and CHECK_SYMBOL_EXISTS and then use the function whenever CHECK_FUNCTION_EXISTS evaluates to TRUE and provide a custom definition when CHECK_SYMBOL_EXISTS was FALSE in that case.
Who is online
Users browsing this forum: Baidu [Spider] and 1 guest