Android Compilation

Compilation and installation of DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
palmerc
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Android Compilation

#1 Post by palmerc »

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.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Android Compilation

#2 Post by J. Riesmeier »

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 :roll: ... at least there is a way to disable building the command line tools in the "apps" subfolder. Just set "BUILD_APPS" to "OFF".

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: Android Compilation

#3 Post by Jan Schlamelcher »

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).

palmerc
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#4 Post by palmerc »

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.

palmerc
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#5 Post by palmerc »

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).
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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: Android Compilation

#6 Post by Jan Schlamelcher »

palmerc wrote:Using macOS.
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: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?
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
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#7 Post by palmerc »

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.

palmerc
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#8 Post by palmerc »

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,

Code: Select all

adb shell mount -o rw,remount rootfs
, 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?

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: Android Compilation

#9 Post by Jan Schlamelcher »

palmerc wrote:if the script doesn't reflect recent changes in the Android SDK tools
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
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#10 Post by palmerc »

I have managed to get past the emulator issue.

Required (in my case) -
  • Waiting for adb shell getprop sys.boot_completed == 1
    adb shell -o rw,remount rootfs
    adb shell mkdir /cache
For some reason the /cache directory is getting created as a file and then erroring out when trying to redirect the result of the tests. So I worked around it by explicitly creating the directory after mounting the system read/write.

Now I have to work pass compilation problems. I'll test and see if it is clang that is the issue by forcing gcc.

palmerc
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#11 Post by palmerc »

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.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: Android Compilation

#12 Post by Jan Schlamelcher »

palmerc wrote:If you want I can clean this up and try to create a pull request for you.
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
Posts: 8
Joined: Mon, 2016-12-19, 19:33

Re: Android Compilation

#13 Post by palmerc »

The script makes a large number of checks using CHECK_FUNCTION_EXISTS, but according to the documentation:
This does not verify that any system header file declares the function, only that it can be found at link time (consider using CheckSymbolExists).
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.

Jan Schlamelcher
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 318
Joined: Mon, 2014-03-03, 09:51
Location: Oldenburg, Germany

Re: Android Compilation

#14 Post by Jan Schlamelcher »

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest