Hi Sergei! Thanks for your help. On 01/10/15 16:16, Sergei Golubchik wrote:
Why would you build host variant for ha_connect.so with the library paths for the target architecture?
I don't actually, I don't know why this happened.
How do you invoke cmake?
In my case cmake is invoked by buildroot. I passed a number of options for disabling some modules or working with galera: -DWITH_WSREP=1 -DWITH_INNODB_DISALLOW_WRITES=1 -DWITH_UNIT_TESTS=0 -DGRN_WITH_MESSAGE_PACK=0 -DWITHOUT_MROONGA=1 -DWITHOUT_XTRADB=1 -DWITH_JEMALLOC=0 -DWITHOUT_TOKUDB=1 -DSTACK_DIRECTION=-1 But then buildroot adds some more magic concerning the toolchain. But...:
Did you check https://mariadb.com/kb/en/mariadb/cross-compiling-mariadb/ ? Regards, Sergei
Ooops. For some reason I completely missed this page. Building only the host variant of import_executables target eases cross-compilation a lot indeed... and fixes my problems. Appart from that I had figured most of this out, or buildroot was taking care of it. I still have a remark: I don't think I can hardcode the value of HAVE_IB_GCC_ATOMIC_BUILTINS as suggested in https://lists.launchpad.net/maria-discuss/msg02911.html because if I want this package accepted in buildroot it must build on all kind of architectures. Therefore: 1. I disabled building xtradb. I also had to patch storage/xtradb/CMakeLists.txt (patch attached) otherwise XTRADB_OK=0 would abort the build even if the module is not requested. 2. I patched storage/innobase/CMakeLists.txt (also attached) in order to use CHECK_C_SOURCE_COMPILES instead of CHECK_C_SOURCE_RUNS, which fails when cross compiling. I'd be happy to have your opinion on these patches. However, I'm currently investigating whether or not the value of HAVE_IB_GCC_ATOMIC_BUILTINS could be guessed from that of BR2_ARCH_HAS_ATOMICS. Cheers, -- Sylvain Raybaud www.green-communications.fr