Android requires NDK 10 - Adobe doesn't support it yet...
rkwright opened this issue · comments
From mark@NYPL:
I'm currently working with the NYPL to produce the Android version of
their upcoming open-source ebook reader.
I'm working on the last major piece of the code, which is the
integration of Adobe's DRM component into the Readium-based reader.
However, I've come up against an apparently blocking issue:
It seems that Readium now incorporates some code (notably future.h)
that seems to require some features from C++11 (std::rethrow_exception,
etc). Unless I'm mistaken, this requires NDK 10 to actually build
correctly, because the newest GCC compiler distributed with NDK 9 seems
to have incomplete support for bits of the standard:
copperhead$ cat test.cpp
#include <exception>
#include <stdexcept>
int main (void)
{
std::exception_ptr p;
try {
throw std::logic_error("ouch!");
} catch (const std::exception& e) {
p = std::current_exception();
}
try {
std::rethrow_exception (p);
} catch (const std::exception& e) {
// Ignore
}
return 0;
}
copperhead$ ./android-toolchains/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-g++
-std=c++11 -o test test.cpp test.cpp: In function 'int main()':
test.cpp:7:3: error: 'exception_ptr' is not a member of 'std'
std::exception_ptr p;
^
test.cpp:7:22: error: expected ';' before 'p'
std::exception_ptr p;
^
test.cpp:12:5: error: 'p' was not declared in this scope
p = std::current_exception();
^
test.cpp:12:9: error: 'current_exception' is not a member of 'std'
p = std::current_exception();
^
test.cpp:16:5: error: 'rethrow_exception' is not a member of 'std'
std::rethrow_exception (p);
^
test.cpp:16:29: error: 'p' was not declared in this scope
std::rethrow_exception (p);
^
The major issue: The Adobe DRM component cannot be built with NDK 10
yet! We're forced to use NDK 9 until Adobe get around to updating
the binary-only components (and there's no timeline given for this).
Is there anything I can do in this situation? Am I actually correct in
thinking that Readium can't be built with NDK 9?
There is one possible solution, but I have not investigated this yet, therefore we still need to spend some time over this in order to verify if it will actually work.
Indeed, the Readium SDK code does use a number of recent features of C++11. However, at that time, not all compilers implemented all features of C++11. Most notably, Visual C++ was lagging behind in a number of them (such as variadic templates).
To work around that problem, it was added to the Readium SDK a matrix of macros, that would work (very roughly) this way: each new feature of C++11 would be defined by a macro. Then, depending on the compiler being used, those macros would be defined as true, indicating that the compiler in question supported a given feature of C++11.
Then, spread in the code, we would have something like this pattern (notice that this is NOT actual Readium SDK code - it is just an example of the pattern):
#ifdef CPP_INITIALIZER_LISTS
GivenCppClass givenCppNewInstance = { 0, 1, 2, 3 };
#else
GivenCppClass givenCppNewInstance(0, 1, 2, 3);
#endif // CPP_INITIALIZER_LISTS
Then, in the file where all those macros are defined (I don't remember the filename from the top of my head) you would have something like this:
#ifdef MSC_VER // If this macro is defined, it means that the code is
// being compiled by Visual C++.
[...]
#define CPP_INITIALIZER_LISTS 1
[...]
#endif // MSC_VER
Therefore, our possible solution would be this: currently the Readium SDK, when it detects that it is being compiled by GCC for Android, takes into account the version of GCC for the NDK 10. We could modify the C++ feature macros described above so that, in the case of Android, it actually takes into account the version of GCC for the NDK 9. That will remove most of the C++11 features, and would allow us to compile the Readium SDK in NDK 9, just like the Adobe DRM.
I have not looked at this solution at all yet: as I said, it requires more investigation to find out if this will solve this current issue.
In my opinion, I don't think it would be a good idea to make Readium work with NDK 9. I think it would be beneficial for everyone involved to instead have Adobe support NDK 10. We're hoping to speak to them again today about this.
Adobe have mentioned that the next release of the DRM connector will be built with NDK 10. We'll know tomorrow when the release is due.
Apparently, the DRM connector release made today is NDK 10 compatible. I am currently working on a different part of the code (due to having to halt work elsewhere after the NDK 9 issue), but I should be finding out in the next week or so whether or not it actually works!
Great. Please let us know how it goes and if the other Readium contributors (besides yourself!) can help.
As of today, it seems that both Readium and the Adobe SDK are NDK 10 compatible! I think this issue can be closed now.
Quote from @jce1028
Adobe re-complied their Adobe Adept connector with NDK 10. In is in their Beta 11.3 and commercial RMSDK ver 12.
Closing, as per above comments.