Hi, Sylvain! On Aug 06, Sylvain Raybaud wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear MariaDB community,
Recently I've been trying to cross-compile MariaDB and I've been running in some problems. I'd like to have your opinion on them.
1) Determining stack direction 2) Building Percona XtraDB 3) Building jemalloc
Let me first tell that I'm trying to build MariaDB galera version 10.0.12. I'm compiling for Arm but may be compiling for something else in the unpredictable future.
1) Determining stack direction
I started by passing the following options to cmake (via the buildroot system):
- -DCMAKE_CROSSCOMPILING=1 -DWITH_WSREP=1 -DWITH_INNODB_DISALLOW_WRITES=1
The first problem I ran into was cmake complaining:
STACK_DIRECTION is not defined. Please specify -DSTACK_DIRECTION=1 or -DSTACK_DIRECTION=-1 when calling cmake.
It seems that STACK_DIRECTION is not automatically determined when cross-compiling. I may determine the correct value for a given target. But if I need a portable solution (and I need one in order to create a buildroot package so that I can build for many different target without too much hassle) I'm not sure what my options are. It seems that the toolchain is aware of this value since stack direction (or more precisely STACK_GROWS_DOWNWARD) is set in ./output/host/opt/ext-toolchain/lib/gcc/arm-none-linux-gnueabi/4.8.1/plugin/include/config/arm/arm.h Maybe there is a way to use this somehow? What do you think?
May be... These files are for building gcc plugins. How do I get to this STACK_GROWS_DOWNWARD? And what if it's not defined or the file doesn't exist?
2) Building Percona XtraDB
For the sake of trying I explicitly set -DSTACK_DIRECTION=1 just to see what happens. Building goes on until it reaches the xtradb module. Then it fails with:
CMake Error at storage/xtradb/CMakeLists.txt:434 (MESSAGE): Percona XtraDB is not supported on this platform
(Here I'll just copy-paste something I wrote on maria-discuss list a few days ago)
This error is triggered in storage/xtradb/CMakeLists.txt when XTRADB_OK is not set; it seems to me that XTRADB_OK is set in either one of the following cases:
a) CMAKE_CROSSCOMPILING is NOT set and some tests are successful (thus setting HAVE_IB_GCC_ATOMIC_BUILTINS)
or
b) We're compiling for MSVC or CMAKE_SYSTEM_NAME is "SunOS" and some other conditions are met.
Since I'm not compiling for MSVC or SunOS and I'm crosscompiling indeed, XTRADB_OK is not set and the error is triggered. Here I'm stuck. I've got the feeling that as such one cannot cross-compile xtradb because XTRADB_OK will never be set; or maybe with proper options passed to cmake the tests would be made elsewhere and HAVE_IB_GCC_ATOMIC_BUILTINS would be set beforehand? Or maybe I should patch this CMakeLists.txt? Or maybe I should just compile without xtradb altogether, if that's possible?
Yes, you can compile without XtraDB. I think -DWITHOUT_XTRADB=1 will do. I don't really know why xtradb's CMakeLists.txt uses CHECK_C_SOURCE_RUNS instead of CHECK_C_SOURCE_COMPILES. It was like this since 2009, when storage/innodb_plugin/plug.in got this check (AC_TRY_RUN back then) for the first time.
Finally I just passed -DXTRADB_OK just to see what would happen, again (obviously there is little chance that it would result in anything usable). And reached problem #3:
3) Building jemalloc
This one fails at configure time with:
checking whether we are cross compiling... configure: error: in `/home/sylvain/DEPOTS/buildroot/output/build/mariadb-galera-10.0.12/extra/jemalloc/build': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'.
Somehow I was expecting that having passed -DCMAKE_CROSSCOMPILING=1 and the host being set by buildroot it would propagate down to the modules... Am I missing something?
At this point I'm out of dirty hacks, even to "see what happens" ;)
To "see what happens" you can disable jemalloc: -DWITH_JEMALLOC=no It was added for TokuDB and TokuDB doesn't build on arm anyway. But strictly speaking, you're right, cmake should pass crosscompiling information down to jemalloc configure. Regards, Sergei