← Back to team overview

maria-developers team mailing list archive

Re: Cross-compiling MariaDB galera cluster


Hi, Sylvain!

On Aug 06, Sylvain Raybaud wrote:
> 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):
> 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

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


Follow ups