[odb-users] ODB on Android

[c.sell at byterefinery.de]

this is from stackoverflow:

Your boost library was built with libc++ (you can tell because it has  
references to std::__ndk1::* rather than just std::*). You need to use  
libc++, not gnustl.

HTH

Zitat von Wolfgang Haupt <haupt.wolfgang at gmail.com>:

> On 14.04.20 14:56, c.sell at byterefinery.de wrote:
>> Hi,
>>
>> IMO and according to my experience, the ODB compiler has no  
>> dependency on the target system, including the c/c++ libraries.  
>> After all, it is just a code generator. As long as it generates  
>> valid standard C++ code, it should work on any system.
>>
>> I have compiled on ealier NDKs without issues.
>>
>> Chris
>
>
> Yeah, that's what I think as well.
> However, until now I face various low level issues that are hard for  
> me to track down.
>
> My run with NDK 17c finished, everything compiled but I'm stuck with  
> a linker error.
> Not sure what's that about, but seems to be related to the standard library.
> //home/a1rwulf/Android/omniyon-depends/arm-linux-androideabi-21-release/lib/libodb-sqlite.a(options.o):options.cxx:function std::__ndk1::basic_filebuf<char, std::__ndk1::char_traits<char> >::imbue(std::__ndk1::locale const&): error: undefined reference to 'std::__ndk1::codecvt<char, char,  
> __mbstate_t>::id'//
> ///home/a1rwulf/Android/omniyon-depends/arm-linux-androideabi-21-release/lib/libodb-sqlite.a(options.o):options.cxx:function std::__ndk1::basic_filebuf<char, std::__ndk1::char_traits<char> >::basic_filebuf(): error: undefined reference to 'std::__ndk1::codecvt<char, char,  
> __mbstate_t>::id'//
> ///home/a1rwulf/Android/omniyon-depends/arm-linux-androideabi-21-release/lib/libodb-sqlite.a(options.o):options.cxx:function std::__ndk1::basic_filebuf<char, std::__ndk1::char_traits<char> >::basic_filebuf(): error: undefined reference to 'std::__ndk1::codecvt<char, char,  
> __mbstate_t>::id'//
> //clang60++: error: linker command failed with exit code 1 (use -v  
> to see invocation)//
> //CMakeFiles/kodi.dir/build.make:538: recipe for target 'libkodi.so' failed//
> //make[2]: *** [libkodi.so] Error 1//
> //CMakeFiles/Makefile2:755: recipe for target  
> 'CMakeFiles/kodi.dir/all' failed//
> //make[1]: *** [CMakeFiles/kodi.dir/all] Error 2//
> //Makefile:129: recipe for target 'all' failed//
> //make: *** [all] Error 2/
>
> BR,
> Wolfgang
>
>
>>
>> Zitat von Wolfgang Haupt <haupt.wolfgang at gmail.com>:
>>
>>> On 14.04.20 12:02, Boris Kolpackov wrote:
>>>> Wolfgang Haupt <haupt.wolfgang at gmail.com> writes:
>>>>
>>>>> And I can cross-compile libodb and libodb-sqlite+libodb-mysql just fine.
>>>>>
>>>>> However I struggle to see how this will work together with the  
>>>>> odb compiler.
>>>> You would normally use native ODB compiler for your development machine.
>>>> So if you are using x86-64 Linux to develop for ARM Android, then you
>>>> would run x86-64 Linux ODB compiler, generate the database support
>>>> source code (the source code is the same for all the platforms), then
>>>> compile that for ARM Android along with your other source code, and
>>>> finally link everything together with cross-compiled libodb*.
>>>>
>>>> It may be possible to build a native ODB compiler for Android but we
>>>> haven't tried (you will most likely need to build GCC from scratch
>>>> with plugin support).
>>>
>>> Hey Boris,
>>>
>>> thx for your clarification - seems the procedure works better when  
>>> I use version 17 of the
>>> android ndk.
>>> I'm still in the compilation process, so I can probably report  
>>> back once it is finished.
>>>
>>> Given the earlier mentioned errors just disappear when using the  
>>> 17 NDK, I wonder how/if it is possible
>>> for the odb compiler (on the host machine) to generate valid c++  
>>> code for the target, when the target probably
>>> uses a completely different standard c/c++ library and has no  
>>> support for GCC at all.
>>>
>>>> It may be possible to build a native ODB compiler for Android but we
>>>> haven't tried (you will most likely need to build GCC from scratch
>>>> with plugin support).
>>> I do not want to go this way either if not possbile, sounds like  
>>> pain to me.
>>> Does that mean you have tried to use odb on a recent android ndk >= 18?
>>>
>>>
>>> Best Regards,
>>> Wolfgang
>>
>>
>>