[Maria-developers] crosscompiling in buildroot: cannot find -laio and other link error
Hi I'm trying to get the latest version of mariadb-galera (10.0.21) into buildroot. I'm running into two errors which I have a feeling are related. But I may be wrong. These problems arise during the build of the host variant of the package. I get the two following errors (build does not stop at the first one because they happen in parallel jobs): 1: Linking CXX shared module ha_connect.so /home/sylvain/git/br/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libxml2.so: error adding symbols: File in wrong format --> for host variant ha_connect.so should be linked against /home/sylvain/git/br/output/host/usr/lib/libxml2.so 2: Linking CXX shared module ha_innodb.so /usr/bin/ld: cannot find -laio The thing is, libaio and libxml2 are both present in /home/sylvain/git/br/output/host/usr/lib/. The link command present in storage/connect/CMakeFiles/connect.dir/link.txt (http://pastebin.com/Qn1ZCw2X) contains: /home/sylvain/git/br/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/lib/libxml2.so which is incorrect, should be: /home/sylvain/git/br/output/host/usr/lib/libxml2.so The link command present in storage/innobase/CMakeFiles/innobase.dir/link.txt (http://pastebin.com/it6W9WVs) does not contain -L/home/sylvain/git/br/output/host/usr/lib/. I think it should. At least, when I manually run this command adding -L/home/sylvain/git/br/output/host/usr/lib, it works. I'm really not sure how these link.txt are generated. I checked connect/CMakeLists.txt and innobase/CMakeLists.txt and could not find anything obvious problem. Beside, toplevel CMakeCache.txt does contain: CMAKE_EXE_LINKER_FLAGS:STRING=-L/home/sylvain/git/br/output/host/lib -L/home/sylvain/git/br/output/host/usr/lib -Wl,-rpath,/home/sylvain/git/br/output/host/usr/lib which seems correct. I don't know why this setting does not reach storage/innobase and I'm also not sure why ha_connect.so tries to link against target variant of libxml2. It basically comes down to have cmake look for shared libraries in the right place, but I don't seem to be able to determine which lever to pull. Any hint as to how to achieve that is therefore welcome. Cheers, -- Sylvain Raybaud www.green-communications.fr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I don't have a solution to these problems yet, but a workaround for #1 and a dirty hack for #2. While these aren't satisfactory, I thought I'd share as they might trigger some ideas for a proper fix. On 25/09/2015 16:36, Sylvain Raybaud wrote:
1: Linking CXX shared module ha_connect.so /home/sylvain/git/br/output/host/usr/arm-buildroot-linux-uclibcgnueabi /sysroot/usr/lib/libxml2.so:
error adding symbols: File in wrong format
--> for host variant ha_connect.so should be linked against /home/sylvain/git/br/output/host/usr/lib/libxml2.so
I passed -DCONNECT_WITH_LIBXML2=0 to cmake
2: Linking CXX shared module ha_innodb.so /usr/bin/ld: cannot find -laio
I applied the following patch to toplevel CMakeLists.txt; - --- a/CMakeLists.txt.orig 2015-09-30 14:02:36.018951019 +0200 +++ b/CMakeLists.txt 2015-09-30 14:05:36.690950130 +0200 @@ -40,6 +40,10 @@ SET(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake) +# Linker fails to find libraries in $(HOST_DIR)/usr/lib. Add this path +# explicitely: +link_directories(${EXPLICIT_LINK_DIR}) + # Distinguish between community and non-community builds, with the # default being a community build. This does not impact the feature # set that will be compiled in; it's merely provided as a hint to and passed -DEXPLICIT_LINK_DIR=$(HOST_DIR)/usr/lib to cmake Now -L$(HOST_DIR)/usr/lib is present in link commands and the build goes smoothly. I think the build rules could be improved in a better way but right now I don't know how. Cheers, Sylvain
The thing is, libaio and libxml2 are both present in /home/sylvain/git/br/output/host/usr/lib/.
The link command present in storage/connect/CMakeFiles/connect.dir/link.txt (http://pastebin.com/Qn1ZCw2X) contains: /home/sylvain/git/br/output/host/usr/arm-buildroot-linux-uclibcgnueabi /sysroot/usr/lib/libxml2.so
which is incorrect, should be:
/home/sylvain/git/br/output/host/usr/lib/libxml2.so
The link command present in storage/innobase/CMakeFiles/innobase.dir/link.txt (http://pastebin.com/it6W9WVs) does not contain -L/home/sylvain/git/br/output/host/usr/lib/. I think it should. At least, when I manually run this command adding -L/home/sylvain/git/br/output/host/usr/lib, it works.
I'm really not sure how these link.txt are generated. I checked connect/CMakeLists.txt and innobase/CMakeLists.txt and could not find anything obvious problem. Beside, toplevel CMakeCache.txt does contain: CMAKE_EXE_LINKER_FLAGS:STRING=-L/home/sylvain/git/br/output/host/lib
- -L/home/sylvain/git/br/output/host/usr/lib
-Wl,-rpath,/home/sylvain/git/br/output/host/usr/lib which seems correct. I don't know why this setting does not reach storage/innobase and I'm also not sure why ha_connect.so tries to link against target variant of libxml2.
It basically comes down to have cmake look for shared libraries in the right place, but I don't seem to be able to determine which lever to pull. Any hint as to how to achieve that is therefore welcome.
Cheers,
- -- Sylvain Raybaud www.green-communications.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWC/xcAAoJEEkkwl4JtJ9yvnYP/0Yk3AEZRtMurmPJ9fAX3JnR lybMrZ5bsBks7GrTA5fP4FNoa4bh+EZgkdjx3VE9aNu1yejHQOLuZYAl0iryJKHZ 2xMr98GbohUZafS3nP2oPaRKi3DdSeUdC/7IcubGOkH7RkaoK2SLKyi6m32l/jz7 LRuwCcmM3TeiRi7YjjZ2sxykc/AAu4ePewU4KHrqwGypokTvroSWTOw3yGgvbpHD TBPWLAGE5fqtaY4gfCOzq6grD/pdhOiI1NYMA8JyEvQV+CkZh2D1wV9J2XYDxBzP nAdZfNc5NJWBQAuYLJPlK+IhAyQTUytgF+zCbkm2IwyGlbtyYxGjgQId21A9MfDW AmJ9cfHuGGkYsX1leqg4FJjDWVuMspVawLxQrUabBLtu8djE6cK5jdLWfT6l+2v3 Gi0rAqG2BTfLMfwBKU5PFEfPTjd5Gve+p0YYI646w5BAExv7pQfodzjuuePvW3Nd hU03LVzSlaT68emcMCdByMegZ21dPgAcnSNtOQuBNOthIY7p7x0d8H7V20zNRg+G mqozzQgo+1GTcPELTcoGmsOZYbJRhn27l8GcjdV1b3MiQehHJoEyEsPNw+w2KDbj 41eh8eFbSaAjSCuNK4rreZrt1mjJpUiWxke+VHppc6vyiDIkpGiyI6/SLs6R/GWL 4K4zLlNrcIIDgiVeQ1it =10zE -----END PGP SIGNATURE-----
Hi, Sylvain! On Sep 25, Sylvain Raybaud wrote:
Hi
I'm trying to get the latest version of mariadb-galera (10.0.21) into buildroot. I'm running into two errors which I have a feeling are related. But I may be wrong.
These problems arise during the build of the host variant of the package. I get the two following errors (build does not stop at the first one because they happen in parallel jobs): ... It basically comes down to have cmake look for shared libraries in the right place, but I don't seem to be able to determine which lever to pull. Any hint as to how to achieve that is therefore welcome.
Why would you build host variant for ha_connect.so with the library paths for the target architecture? How do you invoke cmake? Did you check https://mariadb.com/kb/en/mariadb/cross-compiling-mariadb/ ? Regards, Sergei
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
Hi, Sylvain! On Oct 02, Sylvain Raybaud wrote:
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.
This page is quite recent, I wrote it only a couple of weeks ago.
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.
good point. it's a bug. https://mariadb.atlassian.net/browse/MDEV-8883
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'm not sure we can do that, some of those checks were CHECK_C_SOURCE_COMPILES before and later changed to CHECK_C_SOURCE_RUNS because compiling was not enough (in some corner cases). I think doing CHECK_C_SOURCE_COMPILES in cross-compiling case and CHECK_C_SOURCE_RUNS otherwise could be a reasonable compromise.
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.
Please tell me whether it'll work (or add a comment directly to MDEV-8883) Regards, Sergei
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/10/2015 18:28, Sergei Golubchik wrote:
On Oct 02, Sylvain Raybaud wrote:
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.
good point. it's a bug.
https://mariadb.atlassian.net/browse/MDEV-8883
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'm not sure we can do that, some of those checks were CHECK_C_SOURCE_COMPILES before and later changed to CHECK_C_SOURCE_RUNS because compiling was not enough (in some corner cases).
I think doing CHECK_C_SOURCE_COMPILES in cross-compiling case and CHECK_C_SOURCE_RUNS otherwise could be a reasonable compromise.
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.
Please tell me whether it'll work (or add a comment directly to MDEV-8883)
Hi It seems BR2_ARCH_HAS_ATOMICS cannot be used, because for example on 32bits architectures some atomic operations may not be available even though BR2_ARCH_HAS_ATOMICS is set to true. Therefore your solution should be used. However I just realised that CHECK_C_SOURCE_RUNS should never be invoked by this script in buildroot because it's enclosed in IF(NOT CMAKE_CROSSCOMPILING) [...] ENDIF (https://github.com/MariaDB/server/blob/10.1/storage/innobase/CMakeLists .txt, line #75). Is -DCMAKE_CROSSCOMPILING supposed to passed when invoking cmake or is it supposed to be determined automatically? (I'm also posting this on the bugtracker. Not sure what the good procedure is) Cheers, Sylvain
Regards, Sergei
- -- Sylvain Raybaud www.green-communications.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWHp6ZAAoJEEkkwl4JtJ9yo1UQAIQOZOTi+vZWTlxUJlVZi26g hguTyPrrFutsFjqyKkcxBXJf5jbkVVXhNovGIi0f1ldHZcOkBidx5BJIewJueRy6 36v2ZnLZwyOvEvpvv1ZrrmdG1LsJMKAE6V2PcTJ+W16bSNlIBFUPLivl6wzgbwWp uJFxYWCfWJmRuQ7YlY4bpbu1D3N0NIGcWXzFWHeviORht7KvKyd3REKNefSWLVEH 0WAp2ZVipBu2gg2Af/Aifc1piA9ADGSmdDz6mmh2D76oe364ugqYwvrKgSh8IoIQ hwBXYlPnFwPqXkHYtP/xkNDNAi9PHXjbUe1zX5hz/wld2V4FuTCatET144s6suWE /04IDBEny4YBZatpoh2AlCfjJPpwqp3QB5BdgOBvrIHONWeRDzWvfvt6EovM7SsE QSjZ3/MM3ScpbR4cfRBrYUjyHgW0or9AXGZYHJbhJpGtcX//he2Nc07vTGLwDu7I b+33+IX5VNzVJjO3WF2VSJGxhZfqjht9F2Ziu0r4tz/W0JaN7tfW1QeZhoFszqaZ I91W9l4Ugk01+XMelpI3l5nQiicc+NMY3K/ondH0po1NCiHQi52v9vLNdWeVRL6F 6GHBxbzf9AhrYPhYQL5gqNdqxxoqg4RP881wBZToN/8rW/T4MB5kg1glzDQQ5HgV BlfrxgC1TsJG2JLanZSH =sfiv -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14/10/15 20:27, Sylvain Raybaud wrote:
On 02/10/2015 18:28, Sergei Golubchik wrote:
On Oct 02, Sylvain Raybaud wrote:
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.
good point. it's a bug.
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'm not sure we can do that, some of those checks were CHECK_C_SOURCE_COMPILES before and later changed to CHECK_C_SOURCE_RUNS because compiling was not enough (in some corner cases).
I think doing CHECK_C_SOURCE_COMPILES in cross-compiling case and CHECK_C_SOURCE_RUNS otherwise could be a reasonable compromise.
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.
Please tell me whether it'll work (or add a comment directly to MDEV-8883)
Hi
It seems BR2_ARCH_HAS_ATOMICS cannot be used, because for example on 32bits architectures some atomic operations may not be available even though BR2_ARCH_HAS_ATOMICS is set to true. Therefore your solution should be used.
However I just realised that CHECK_C_SOURCE_RUNS should never be invoked by this script in buildroot because it's enclosed in
IF(NOT CMAKE_CROSSCOMPILING) [...] ENDIF
(https://github.com/MariaDB/server/blob/10.1/storage/innobase/CMakeLis ts
.txt,
line #75).
Is -DCMAKE_CROSSCOMPILING supposed to passed when invoking cmake or is it supposed to be determined automatically?
(I'm also posting this on the bugtracker. Not sure what the good procedure is)
Cheers,
Sylvain
Hi If I disable these tests by explicitely passing -DCMAKE_CROSSCOMPILING then the build fails with: [ 66%] /home/sylvain/git/br/output/build/mariadb-galera-10.0.21/storage/innobas e/srv/srv0conc.cc: In function ‘void srv_conc_enter_innodb_without_atomics(trx_t*)’: /home/sylvain/git/br/output/build/mariadb-galera-10.0.21/storage/innobas e/srv/srv0conc.cc:425:45: error: ‘wsrep_thd_is_brute_force’ was not declared in this scope wsrep_thd_is_brute_force(trx->mysql_thd)) { ^ I've not yet investigated this. Regards, Sylvain - -- Sylvain Raybaud www.green-communications.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWIOwoAAoJEEkkwl4JtJ9yR1MP/2wN7P6aOUKbw2NGxy8eeUrX Lse/KvoL9iqikc21hIl59w+E89yjGqlZ6nS6vZ35Qods7Q52JT1fLwJA2C8UwOGw 32rYUNKjW4nFV4q7RpqJEdVOGoj28UEJKno6RiJ0oju6mIlqrlyjFN1pzOPaJ3Lu XelZeyxb6VwMDqAvWk/HE+NdB9oWsrgGtihIb9QrOEXUatba3NyMi+lXusedYe5P Bj5ABFm2Dro2thJuvGcFwyAEQ3+vElkTQovH64xt/jGBtltXmIcnK6pNlpdQW2X+ 0DCGH6Uz/Oda9CJO7CjxXxFvkn0wORfMmnprxBu4N+BErsF6kTA6fnlvPeNpynaW 6o9YiMJLNYxqzXWVQu+MGOmtSgN3c2qZgan52COYbBTyFoNW42Y78RKtfBHSo6dy YfdlvQNY2832Do7mPBvbptMuT1WbPgv32CGS7GLI8S1SjUb85IxKmLNevSe9GdSr fiLMVITsqSA7HCWy9dQxKKNUHpqEro1yxKVX88syjIFK9C639j8DGDu9ElLCc8Lg EQwDXA9Qxo+tsgMb5QEmh18zUDayC8eABVVlJXvBXi8fwfdYhkkGoAdBCtnG737v bIokLeMZlMPwzyL7nDSoqSxJv40BKpmc/kz00CSZxZ7tuEnRkvACOuKcc4lh/ERv 91o4A8+uFyHt9aI/uEyK =Xpjt -----END PGP SIGNATURE-----
On 02/10/2015 18:28, Sergei Golubchik wrote:
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'm not sure we can do that, some of those checks were CHECK_C_SOURCE_COMPILES before and later changed to CHECK_C_SOURCE_RUNS because compiling was not enough (in some corner cases).
I think doing CHECK_C_SOURCE_COMPILES in cross-compiling case and CHECK_C_SOURCE_RUNS otherwise could be a reasonable compromise.
Hi For this I propose the attached patch. Tested in my buildroot environment, works here. In my case I do have atomic intrinsics, but trying to build without them fails (https://mariadb.atlassian.net/browse/MDEV-9002). Cheers and thanks for your help, -- Sylvain Raybaud www.green-communications.fr
participants (2)
-
Sergei Golubchik -
Sylvain Raybaud