[Maria-developers] Cross-compiling MariaDB galera cluster
-----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? 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? 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" ;) Cheers, - -- Sylvain Raybaud www.green-communications.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJT4ke/AAoJEEkkwl4JtJ9yJW0QALBz3wj0VsfMtUBUabP13q74 ++y1AiCLZ0js+UGCqxB9PVz4yvhhnMAz8QnPpH37XJtDm+VaJBQTEZL65CHF3nlr dHe46/q/wswlbdhNsQu6JmMe3JoOe2TFbjDenQMiUvW9mOilt86ioveHVLGYbpnq 5LYMrPlYXUBpDcxEYXXbTpIHsAoHUrOE1Gj5AsxwbUvQuHDDr9M/Ws01iIXLbzT8 0pImhgBPYUwqaj9tJnPkls+9LzoOb2m269n9TCbmWk0ixakpHjeNMn5lnRDhOwNh AKkHrGdMUomSBca4G0kQoeNxwC2rCjO8+bRxjh7v6GTdME/sgsgn3yOv2EznldUr tFaO/JfraHSUgmiRyVo41U3uTESxZKRJYOV9IqUhl4HiS85D5oa/bD6l84rhx95J 52/hUoApoStr8tSk0tzXk1/UWJEQ3fUZ7XoXqgWq+c1uMgbgZftAAqAw7Xvmc88t tf69FqBzw5dpf8Kg0I7iAggBpBLIWGJwnlVvcmLY4UUE1cDFfZstMBSXaS155LQF VClK+ytE2Ef8oAB9/nlMXgg4b3WXlD0PRQDRTNIwCAzdvsuu+S0q64xLtw/JYnLl KPcLWfwXy+kRhT+vtUWtqMjjkSQ3e6rJDybK11vgYIAWm/Xfk5s8i0g7Bgmnf3wp JGYUAR285gY0XMqL6LmU =vBo4 -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I'm finally working on this again. On 14/08/2014 14:48, Sergei Golubchik wrote:
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?
After discussing this issue with the buildroot community it seems that it's not a good idea to try to use this file, at least with buildroot. Since most modern architectures have a stack that grows down. The only exception I know of is PA-RISC and it seems it's not supported by buildroot. Therefore I'll juste hardcode the correct value (-1). I'm sorry I can't propose a better solution :( However I've read here and there (for example [1]) that trying to determine to automatically determine the stack direction wasn't too reliable... So really, I don't know, but maybe this value should be harcoded? For example in an lsit of pairs (arch,stack_direction)? [1] http://stackoverflow.com/questions/664744/what-is-the-direction-of-stack-gro... Regards, - -- Sylvain Raybaud www.green-communications.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUPQ7nAAoJEEkkwl4JtJ9ygQkP/1wifqn7zQdByOvr+RTejfhS fYBIxgZ/HTfZAM0RpaIaJdcuTtfU++ITWr9NFQ/V/PNvSququ6NzRgTD2w5D+2ob nSj60uSCWDFkpwyMMQEhei9tZRZiMj+uaLCULkWDJwvsVLZ89uxGzOeW0YtFRAAA NStD1BPv8QzksRftDVZ/sLcImlhLvy+TsFrht8Ol48gOdQAtkWRVBu4FSUS0kyEF sXm12Ms9fr3bQyCkfm0FaWzUdrSvT74Mag6j2cbNB9pPRGzX3+I+mj4tTYHEqKx1 agK/hokFFFtEtPrYHo2aBVXy7TqoUg7Ra2kI5Vum9aJFnhdOBmxFzBKCKL/AdbeH s0B9X1WX6vYCN3o18EhUKJvun9yBtxDVVySxsMc/JWFU+UNqYsQe1eMm9r0qCpJQ 6CLff/NsNlNAjiBfDkR+SR0aUaMP6hYNBMb0O6u5W2LQhvlF0T42XYtlRqrnYsHn Ye8IDDMesmheSt5r4FpmZWANqcpiSw+/ZSucIc5qP9wRlSVj50n9r3vvZ48a13Pq qEaC6g/rZbQo++dXRMa8CbRxefSrYaZqwMJVXO3S/nvulPeQAu86iVISh3dcGl8Q D9kvC5owyW54psKcE34XgTQ+Bfb7/2Ij1dZ/0QTZSEqX0HW0WcLWD25zyWsRDJVp L9bwOtcNyAu2HYfpwOqx =FDe0 -----END PGP SIGNATURE-----
Hi again On 14/08/2014 14:48, Sergei Golubchik wrote:
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.
Unfortunately it seems that even if I set -DWITHOUT_XTRADB=1 the test is still run: $ cmake -DWITHOUT_XTRADB=1 .. [...] CMake Error at storage/xtradb/CMakeLists.txt:435 (MESSAGE): Percona XtraDB is not supported on this platform -- Configuring incomplete, errors occurred! [...] Is there an easy workaround? It seems to me that CONFIGURE_PLUGINS (defined in cmake/plugin.cmake) will try to configure everything in storage/*. Maybe this should be patched? Or maybe storage/xtradb/CMakeList.txt should be modified to exit silently if WITHOUT_XTRADB if set. For example the attached "quick and dirty" patch seems to do the trick for me. Regards, -- Sylvain Raybaud www.green-communications.fr
Good afternoon, On 14/10/2014 14:58, Sylvain Raybaud wrote:
Hi again
On 14/08/2014 14:48, Sergei Golubchik wrote:
Yes, you can compile without XtraDB. I think -DWITHOUT_XTRADB=1 will do.
[...]
Unfortunately it seems that even if I set -DWITHOUT_XTRADB=1 the test is still run:
$ cmake -DWITHOUT_XTRADB=1 .. [...] CMake Error at storage/xtradb/CMakeLists.txt:435 (MESSAGE): Percona XtraDB is not supported on this platform
-- Configuring incomplete, errors occurred! [...]
Is there an easy workaround?
It seems to me that CONFIGURE_PLUGINS (defined in cmake/plugin.cmake) will try to configure everything in storage/*. Maybe this should be patched? Or maybe storage/xtradb/CMakeList.txt should be modified to exit silently if WITHOUT_XTRADB if set. For example the attached "quick and dirty" patch seems to do the trick for me.
FYI, the same problem still holds with mariadb galera cluster 10.0.14, fixed by the same quick and dirty patch with very minor modifications (line numbers). regards, -- Sylvain Raybaud www.green-communications.fr
participants (2)
-
Sergei Golubchik -
Sylvain Raybaud