Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-12 Thread Otto Kekäläinen
Hello!

Just to follow up on this topic, the riscv64 build on Debian has
worked perfectly since last upload. The builds and test suites have
never run this well ever before for MariaDB 10.5 on so many platforms:
https://buildd.debian.org/status/package.php?p=mariadb-10.5

Thanks Aurelien!

PS. Please Aurelien submit your patches upstream as well.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-07 Thread Otto Kekäläinen
Hello!

> Can we use the patch I proposed earlier in this bug report? I have
> tested it on riscv64 and it builds. I can do another try with the
> changes from the latest upload and propose a MR on salsa.

Sorry, I somehow missed this. Also other "subscribers" of this bug
missed it since the Debian bug system does not automatically include
everybody as the recipient of new messages in a bug.

Tested your patch in an upload to experimental and it worked!

See
https://buildd.debian.org/status/package.php?p=mariadb-10.5=experimental
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commits/master

Could you Aurelien please submit your patch upstream for permanent inclusion?

Thanks!



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-06 Thread Daniel Black
Thanks for the tests.

Looks like removing the rocksdb part of the patch was overly ambitious.
Also need atomics on the unittest/mysys/my_atomic-t.c

I've updated:

https://github.com/MariaDB/server/tree/bb-10.3-danielblack-MDEV-23892-pr979

aka
https://github.com/MariaDB/server/commit/6171ecee13aea76d474919235568509835b25d98

I'm running a little blind without the CI so I appreciate your help.


On Wed, Oct 7, 2020 at 5:30 AM Otto Kekäläinen  wrote:
>
> Hello!
>
> ti 6. lokak. 2020 klo 14.41 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Thanks Daniel!
> >
> > I applied it in
> > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
> > and tested on Launchpad to ensure that it does not at least regress :)
> > https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=_state=all
> >
> > I will soon upload mariadb-10.5 1:10.5.5-2 and then we will get a
> > result of all archs.
>
> Unfortunately 1:10.5.5-2 with the patch above failed to build on
> riscv64 in Debian:
> https://buildd.debian.org/status/package.php?p=mariadb-10.5



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-06 Thread Aurelien Jarno
On 2020-10-06 21:30, Otto Kekäläinen wrote:
> Hello!
> 
> ti 6. lokak. 2020 klo 14.41 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Thanks Daniel!
> >
> > I applied it in
> > https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
> > and tested on Launchpad to ensure that it does not at least regress :)
> > https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=_state=all
> >
> > I will soon upload mariadb-10.5 1:10.5.5-2 and then we will get a
> > result of all archs.
> 
> Unfortunately 1:10.5.5-2 with the patch above failed to build on
> riscv64 in Debian:
> https://buildd.debian.org/status/package.php?p=mariadb-10.5

Can we use the patch I proposed earlier in this bug report? I have
tested it on riscv64 and it builds. I can do another try with the
changes from the latest upload and propose a MR on salsa.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-06 Thread Otto Kekäläinen
Hello!

ti 6. lokak. 2020 klo 14.41 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Thanks Daniel!
>
> I applied it in
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
> and tested on Launchpad to ensure that it does not at least regress :)
> https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=_state=all
>
> I will soon upload mariadb-10.5 1:10.5.5-2 and then we will get a
> result of all archs.

Unfortunately 1:10.5.5-2 with the patch above failed to build on
riscv64 in Debian:
https://buildd.debian.org/status/package.php?p=mariadb-10.5



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-06 Thread Otto Kekäläinen
Thanks Daniel!

I applied it in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/061acd336f7cdaa16ff0271feafce4a2551ab903
and tested on Launchpad to ensure that it does not at least regress :)
https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=_state=all

I will soon upload mariadb-10.5 1:10.5.5-2 and then we will get a
result of all archs.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-05 Thread Daniel Black
https://jira.mariadb.org/browse/MDEV-23892 created for this issue.

https://github.com/MariaDB/server/pull/979 modified to be more minimal
https://github.com/MariaDB/server/commit/970984e9f9b385d7a64d896baa437a40d65d3f2f
is now in testing.

Comments welcome.

Testing on riscv64 is also very welcome.

On Mon, Oct 5, 2020 at 7:14 AM Otto Kekäläinen  wrote:
>
> Hello!
>
> I plan to upload mariadb-10.5 1:10.5.5-2 in a couple of days and I
> would be happy to receive merge requests regarding getting riscv64 to
> build properly on Debian.
>
> http://bugs.debian.org/933151
> https://wiki.debian.org/Teams/MySQL/patches
>
>
> ti 29. syysk. 2020 klo 16.48 Otto Kekäläinen (o...@debian.org) kirjoitti:
> >
> > Hello!
> >
> > Adding Christian and Dimitri to the recipients, since I think it was
> > Dimitri who patched the Ubuntu version of cmake for this.
> >
> >
> > ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti:
> > >
> > > On 2020-09-28 15:12, Otto Kekäläinen wrote:
> > > > After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> > > > fails with these:
> > > >
> > > > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> > > > reference to `__atomic_compare_exchange_1'
> > > >
> > > > The odd thing is that an identical build on Ubuntu Groovy passes OK:
> > > > https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz
> > >
> > > Ubuntu has patched their version of cmake to link with -latomic on
> > > riscv64. While patching cmake is a really good idea, the fix is wrong,
> > > the correct think to do is to link with -pthread instead of -lpthread,
> > > and do that for all architectures.
> > >
> > > This is the strategy followed for mariadb-10.5 in the attached patch. I
> > > have tested it and it builds fine on Debian.
>
>
>
> --
> - Otto



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-10-04 Thread Otto Kekäläinen
Hello!

I plan to upload mariadb-10.5 1:10.5.5-2 in a couple of days and I
would be happy to receive merge requests regarding getting riscv64 to
build properly on Debian.

http://bugs.debian.org/933151
https://wiki.debian.org/Teams/MySQL/patches


ti 29. syysk. 2020 klo 16.48 Otto Kekäläinen (o...@debian.org) kirjoitti:
>
> Hello!
>
> Adding Christian and Dimitri to the recipients, since I think it was
> Dimitri who patched the Ubuntu version of cmake for this.
>
>
> ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti:
> >
> > On 2020-09-28 15:12, Otto Kekäläinen wrote:
> > > After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> > > fails with these:
> > >
> > > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> > > reference to `__atomic_compare_exchange_1'
> > >
> > > The odd thing is that an identical build on Ubuntu Groovy passes OK:
> > > https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz
> >
> > Ubuntu has patched their version of cmake to link with -latomic on
> > riscv64. While patching cmake is a really good idea, the fix is wrong,
> > the correct think to do is to link with -pthread instead of -lpthread,
> > and do that for all architectures.
> >
> > This is the strategy followed for mariadb-10.5 in the attached patch. I
> > have tested it and it builds fine on Debian.



-- 
- Otto



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-30 Thread Daniel Black
Upstream PR is very welcome.

Occasional nagging also.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-29 Thread Otto Kekäläinen
Hello!

Adding Christian and Dimitri to the recipients, since I think it was
Dimitri who patched the Ubuntu version of cmake for this.


ti 29. syysk. 2020 klo 0.22 Aurelien Jarno (aurel...@aurel32.net) kirjoitti:
>
> On 2020-09-28 15:12, Otto Kekäläinen wrote:
> > After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> > fails with these:
> >
> > /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> > reference to `__atomic_compare_exchange_1'
> >
> > The odd thing is that an identical build on Ubuntu Groovy passes OK:
> > https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz
>
> Ubuntu has patched their version of cmake to link with -latomic on
> riscv64. While patching cmake is a really good idea, the fix is wrong,
> the correct think to do is to link with -pthread instead of -lpthread,
> and do that for all architectures.
>
> This is the strategy followed for mariadb-10.5 in the attached patch. I
> have tested it and it builds fine on Debian.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-28 Thread Aurelien Jarno
On 2020-09-28 15:12, Otto Kekäläinen wrote:
> After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
> fails with these:
> 
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> 
> The odd thing is that an identical build on Ubuntu Groovy passes OK:
> https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz

Ubuntu has patched their version of cmake to link with -latomic on
riscv64. While patching cmake is a really good idea, the fix is wrong,
the correct think to do is to link with -pthread instead of -lpthread,
and do that for all architectures.

This is the strategy followed for mariadb-10.5 in the attached patch. I
have tested it and it builds fine on Debian.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- mariadb-10.5-10.5.5/debian/patches/riscv64-link-pthread.patch
+++ mariadb-10.5-10.5.5/debian/patches/riscv64-link-pthread.patch
@@ -0,0 +1,10 @@
+--- mariadb-10.5-10.5.5.orig/configure.cmake
 mariadb-10.5-10.5.5/configure.cmake
+@@ -135,6 +135,7 @@ IF(UNIX)
+   IF(NOT LIBRT)
+ MY_SEARCH_LIBS(clock_gettime rt LIBRT)
+   ENDIF()
++  set(THREADS_PREFER_PTHREAD_FLAG ON)
+   FIND_PACKAGE(Threads)
+ 
+   SET(CMAKE_REQUIRED_LIBRARIES 
diff -Nru mariadb-10.5-10.5.5/debian/patches/series mariadb-10.5-10.5.5/debian/patches/series
--- mariadb-10.5-10.5.5/debian/patches/series
+++ mariadb-10.5-10.5.5/debian/patches/series
@@ -13,3 +13,4 @@
 prevent-executable-stack-due-to-objects-compiled-fro.patch
 env-perl-usr-bin-perl.patch
 fix-spelling.patch
+riscv64-link-pthread.patch


Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-28 Thread Otto Kekäläinen
After uploading mariadb-10.5 1:10.5.5-1 to Debian the build still
fails with these:

/usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
reference to `__atomic_compare_exchange_1'

The odd thing is that an identical build on Ubuntu Groovy passes OK:
https://launchpadlibrarian.net/499652421/buildlog_ubuntu-groovy-riscv64.mariadb-10.5_1%3A10.5.5-1~ubuntu20.10.1~1601274184.7ad164279+master_BUILDING.txt.gz



Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-21 Thread Daniel Black
I'm probably going to add a fix to
https://github.com/MariaDB/server/blob/10.5/configure.cmake#L865 to
include libatomic globally if needed.

AIX needs it too.

On Mon, Sep 21, 2020 at 7:56 AM Otto Kekäläinen  wrote:
>
> Package: mariadb-10.5
> Version: 1:10.5.5-1~exp1
>
> The riscv64 builds on Debian build are still failing for latest mariadb-105:
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=riscv64=1%3A10.5.5-1%7Eexp1=1599937965=0
>
>
> 
> [ 62%] Building CXX object
> storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o
> cd /<>/builddir/storage/mroonga &&
> /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H
> -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED
> -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1
> -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS
> -I/<>/wsrep-lib/include
> -I/<>/wsrep-lib/wsrep-API/v26
> -I/<>/builddir/include
> -I/<>/builddir/storage/mroonga
> -I/<>/storage/mroonga
> -I/<>/storage/mroonga/lib -I/<>/include
> -I/<>/sql -I/<>/regex -I/<>
> -I/<>/storage/mroonga/vendor/groonga/include
> -I/<>/builddir/extra/wolfssl
> -I/<>/extra/wolfssl/wolfssl
> -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
> -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g
> -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
> -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
> -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
> -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
> -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC
> -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -o
> CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o -c
> /<>/storage/mroonga/lib/mrn_operation.cpp
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
> `rocksdb::ConcurrentArena::ApproximateMemoryUsage() const':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/memory/concurrent_arena.h:67:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
> `std::__atomic_base::compare_exchange_weak(bool&, bool,
> std::memory_order, std::memory_order)':
> /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/10/bits/atomic_base.h:464:
> more undefined references to `__atomic_compare_exchange_1' follow
> [ 62%] Building CXX object
> storage/perfschema/CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o
> cd /<>/builddir/storage/perfschema &&
> /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DEMBEDDED_LIBRARY
> -DHAVE_CONFIG_H -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64
> -I/<>/wsrep-lib/include
> -I/<>/wsrep-lib/wsrep-API/v26
> -I/<>/builddir/include -I/<>
> -I/<>/include -I/<>/sql
> -I/<>/builddir/sql
> -I/<>/builddir/storage/perfschema
> -I/<>/builddir/extra/wolfssl
> -I/<>/extra/wolfssl/wolfssl
> -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
> -fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g
> -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
> -Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
> -DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
> -Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
> -Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings
> -Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_OPENSSL -DHAVE_WOLFSSL
> -DWOLFSSL_USER_SETTINGS -fPIC -fvisibility=hidden -std=gnu++11 -o
> CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o -c
> /<>/storage/perfschema/pfs_engine_table.cc
> [ 62%] Building CXX object
> storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_database.cpp.o
> cd /<>/builddir/storage/mroonga &&
> /usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H
> -DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED
> -DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1
> -D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS
> -I/<>/wsrep-lib/include
> -I/<>/wsrep-lib/wsrep-API/v26
> -I/<>/builddir/include
> -I/<>/builddir/storage/mroonga
> -I/<>/storage/mroonga
> -I/<>/storage/mroonga/lib -I/<>/include
> -I/<>/sql -I/<>/regex -I/<>
> -I/<>/storage/mroonga/vendor/groonga/include
> -I/<>/builddir/extra/wolfssl
> -I/<>/extra/wolfssl/wolfssl
> -I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time 

Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-09-20 Thread Otto Kekäläinen
Package: mariadb-10.5
Version: 1:10.5.5-1~exp1

The riscv64 builds on Debian build are still failing for latest mariadb-105:
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.5=riscv64=1%3A10.5.5-1%7Eexp1=1599937965=0



[ 62%] Building CXX object
storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o
cd /<>/builddir/storage/mroonga &&
/usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H
-DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED
-DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1
-D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS
-I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/builddir/storage/mroonga
-I/<>/storage/mroonga
-I/<>/storage/mroonga/lib -I/<>/include
-I/<>/sql -I/<>/regex -I/<>
-I/<>/storage/mroonga/vendor/groonga/include
-I/<>/builddir/extra/wolfssl
-I/<>/extra/wolfssl/wolfssl
-I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
-fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g
-static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
-Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
-DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
-Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC
-Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -o
CMakeFiles/mroonga.dir/lib/mrn_operation.cpp.o -c
/<>/storage/mroonga/lib/mrn_operation.cpp
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
`rocksdb::ConcurrentArena::ApproximateMemoryUsage() const':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/memory/concurrent_arena.h:67:
undefined reference to `__atomic_compare_exchange_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
`std::__atomic_base::compare_exchange_weak(bool&, bool,
std::memory_order, std::memory_order)':
/usr/include/c++/10/bits/atomic_base.h:464: undefined reference to
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: 
librocksdblib.a(memtable.cc.o):/usr/include/c++/10/bits/atomic_base.h:464:
more undefined references to `__atomic_compare_exchange_1' follow
[ 62%] Building CXX object
storage/perfschema/CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o
cd /<>/builddir/storage/perfschema &&
/usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DEMBEDDED_LIBRARY
-DHAVE_CONFIG_H -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64
-I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include -I/<>
-I/<>/include -I/<>/sql
-I/<>/builddir/sql
-I/<>/builddir/storage/perfschema
-I/<>/builddir/extra/wolfssl
-I/<>/extra/wolfssl/wolfssl
-I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
-fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g
-static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
-Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
-DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
-Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings
-Wdate-time -D_FORTIFY_SOURCE=2 -DHAVE_OPENSSL -DHAVE_WOLFSSL
-DWOLFSSL_USER_SETTINGS -fPIC -fvisibility=hidden -std=gnu++11 -o
CMakeFiles/perfschema_embedded.dir/pfs_engine_table.cc.o -c
/<>/storage/perfschema/pfs_engine_table.cc
[ 62%] Building CXX object
storage/mroonga/CMakeFiles/mroonga.dir/lib/mrn_database.cpp.o
cd /<>/builddir/storage/mroonga &&
/usr/bin/riscv64-linux-gnu-g++ -DDBUG_TRACE -DHAVE_CONFIG_H
-DMRN_GROONGA_EMBEDDED -DMRN_GROONGA_NORMALIZER_MYSQL_EMBEDDED
-DMYSQL_DYNAMIC_PLUGIN -DWITH_GROONGA_NORMALIZER_MYSQL=1
-D_FILE_OFFSET_BITS=64 -Dmroonga_EXPORTS
-I/<>/wsrep-lib/include
-I/<>/wsrep-lib/wsrep-API/v26
-I/<>/builddir/include
-I/<>/builddir/storage/mroonga
-I/<>/storage/mroonga
-I/<>/storage/mroonga/lib -I/<>/include
-I/<>/sql -I/<>/regex -I/<>
-I/<>/storage/mroonga/vendor/groonga/include
-I/<>/builddir/extra/wolfssl
-I/<>/extra/wolfssl/wolfssl
-I/<>/extra/wolfssl/wolfssl/wolfssl -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
-fPIC -fstack-protector --param=ssp-buffer-size=4 -O2 -g
-static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
-Wno-uninitialized -fno-omit-frame-pointer -D_FORTIFY_SOURCE=2
-DDBUG_OFF -Wall -Wextra -Wformat-security -Wno-format-truncation
-Wno-init-self -Wno-nonnull-compare -Wno-unused-parameter
-Woverloaded-virtual -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC
-Wdate-time -D_FORTIFY_SOURCE=2 

Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-08-23 Thread Aurelien Jarno
Hi,

On 2020-08-23 13:39, Otto Kekäläinen wrote:
> The new .24 failed on Debian builders now with:
> 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.24-1=1598114515=0
> 
> cd /<>/builddir/storage/spider &&
> /usr/bin/riscv64-linux-gnu-g++  -DDBUG_TRACE -DHAVE_CONFIG_H
> -DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64 -Dspider_EXPORTS
> -I/<>/builddir/include
> -I/<>/storage/spider/hs_client -I/<>/include
> -I/<>/sql -I/<>/extra/yassl/include
> -I/<>/extra/yassl/taocrypt/include  -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
> -fPIC -fstack-protector --param=ssp-buffer-size=4 -fno-rtti
> -DHAVE_HANDLERSOCKET -O2 -g -static-libgcc -fno-omit-frame-pointer
> -fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF
> -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self
> -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
> -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC   -Wdate-time
> -D_FORTIFY_SOURCE=2 -o CMakeFiles/spider.dir/spd_db_conn.cc.o -c
> /<>/storage/spider/spd_db_conn.cc
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
> `rocksdb::ConcurrentArena::ApproximateMemoryUsage() const':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/memory/concurrent_arena.h:67:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
> `std::__atomic_base::compare_exchange_weak(bool&, bool,
> std::memory_order, std::memory_order)':
> /usr/include/c++/10/bits/atomic_base.h:464: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/10/bits/atomic_base.h:464: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/10/bits/atomic_base.h:464:
> more undefined references to `__atomic_compare_exchange_1' follow
> [ 71%] Building CXX object storage/spider/CMakeFiles/spider.dir/spd_conn.cc.o
> cd /<>/builddir/storage/spider &&
> /usr/bin/riscv64-linux-gnu-g++  -DDBUG_TRACE -DHAVE_CONFIG_H
> -DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64 -Dspider_EXPORTS
> -I/<>/builddir/include
> -I/<>/storage/spider/hs_client -I/<>/include
> -I/<>/sql -I/<>/extra/yassl/include
> -I/<>/extra/yassl/taocrypt/include  -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
> -fPIC -fstack-protector --param=ssp-buffer-size=4 -fno-rtti
> -DHAVE_HANDLERSOCKET -O2 -g -static-libgcc -fno-omit-frame-pointer
> -fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF
> -Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self
> -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
> -Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC   -Wdate-time
> -D_FORTIFY_SOURCE=2 -o CMakeFiles/spider.dir/spd_conn.cc.o -c
> /<>/storage/spider/spd_conn.cc
> [ 71%] Building CXX object
> storage/perfschema/CMakeFiles/perfschema_embedded.dir/table_file_instances.cc.o
> cd /<>/builddir/storage/perfschema &&
> /usr/bin/riscv64-linux-gnu-g++  -DDBUG_TRACE -DHAVE_CONFIG_H
> -DMYSQL_SERVER -D_FILE_OFFSET_BITS=64
> -I/<>/builddir/include -I/<>
> -I/<>/include -I/<>/sql
> -I/<>/builddir/sql -I/<>/extra/yassl/include
> -I/<>/extra/yassl/taocrypt/include  -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
> -fPIC -fstack-protector --param=ssp-buffer-size=4 -fno-rtti -O2 -g
> -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing
> -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF -Wall -Wextra
> -Wformat-security -Wno-format-truncation -Wno-init-self
> -Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
> -Wnon-virtual-dtor -Wvla -Wwrite-strings   -Wdate-time
> -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -o
> CMakeFiles/perfschema_embedded.dir/table_file_instances.cc.o -c
> /<>/storage/perfschema/table_file_instances.cc
> collect2: error: ld returned 1 exit status
> make[4]: *** [storage/rocksdb/CMakeFiles/sst_dump.dir/build.make:89:
> storage/rocksdb/sst_dump] Error 1
> make[4]: Leaving directory '/<>/builddir'
> make[3]: *** [CMakeFiles/Makefile2:7909:
> storage/rocksdb/CMakeFiles/sst_dump.dir/all] Error 2
> make[3]: *** Waiting for unfinished jobs

This libatomic issue is problematic for packages using cmake. libatomic
is automatically added to the link process when thread support is
enabled, ie when linking with -pthread. However cmake insists in linking
directly with the thread library using -lpthread, which doesn't enable
full thread supports (as another example it doesn't define __REENTRANT
on GNU/Linux or _MT on 

Bug#933151: mariadb-10.3: FTBFS on riscv64

2020-08-23 Thread Otto Kekäläinen
Hello!

Following up on the MariaDB riscv64 build issue.

In MariaDB 10.3.24 the libatomic on RocksDB patch at
https://github.com/mariadb/server/commit/715beee46abb4c29bffd6f9c5fd5ee95da55bf4f
was applied and thus MariaDB issue
https://jira.mariadb.org/browse/MDEV-23051 was closed.

Conversation was at https://github.com/MariaDB/server/pull/1617 and
related libatomics PR for MariaDB in
https://github.com/MariaDB/server/pull/979

Upstream RocksDB issue https://github.com/facebook/rocksdb/issues/7051
and PR https://github.com/facebook/rocksdb/pull/7060 which is still
open.

Ubuntu had workarounds that are now removed and thus
https://bugs.launchpad.net/ubuntu/+source/mariadb-10.3/+bug/1876814
and https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/28
are closed.

The MariaDB 10.3.23 with patches in Debian (1:10.3.23-1) migrated to
Ubuntu and built at
https://launchpad.net/ubuntu/+source/mariadb-10.3/1:10.3.23-1/+build/19854446

The MariaDB 1:10.3.23-1 release however failed to build on Debian
riscv64 at 
https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.23-1=1594031756=0


The MariaDB 10.3.24 release is verified to build on riscv64 at
https://launchpad.net/~otto/+archive/ubuntu/mariadb/+builds?build_text=_state=all

However, when I uploaded it to Debian yesterday the Debian riscv64
build still fails at
https://buildd.debian.org/status/package.php?p=mariadb-10.3



The .23 version failed on Debian with:

https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.23-1=1594031756=0

cd /<>/builddir/storage/rocksdb && /usr/bin/cmake -E
cmake_link_script CMakeFiles/mysql_ldb.dir/link.txt --verbose=1
/usr/bin/riscv64-linux-gnu-g++  -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
-fPIC -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4
-fno-rtti -O2 -g -static-libgcc -fno-omit-frame-pointer
-fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF
-Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
-Wnon-virtual-dtor -Wvla -Wwrite-strings  -Wl,-z,relro -Wl,-z,now
CMakeFiles/mysql_ldb.dir/tools/mysql_ldb.cc.o  -o mysql_ldb  -lpthread
librocksdb_tools.a librocksdb_aux_lib.a ../../dbug/libdbug.a
librocksdblib.a -llz4 -lsnappy -lzstd -lrt -latomic
../../mysys/libmysys.a ../../dbug/libdbug.a ../../mysys/libmysys.a -lz
../../strings/libstrings.a -lpthread -lm -ldl
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
`rocksdb::SpinMutex::lock()':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/mutexlock.h:117:
undefined reference to `__atomic_compare_exchange_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
`std::__atomic_base::compare_exchange_weak(bool&, bool,
std::memory_order, std::memory_order)':
/usr/include/c++/9/bits/atomic_base.h:457: undefined reference to
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/9/bits/atomic_base.h:457: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: 
librocksdblib.a(memtable.cc.o):/usr/include/c++/9/bits/atomic_base.h:457:
more undefined references to `__atomic_compare_exchange_1' follow
collect2: error: ld returned 1 exit status
make[4]: *** [storage/rocksdb/CMakeFiles/sst_dump.dir/build.make:89:
storage/rocksdb/sst_dump] Error 1
make[4]: Leaving directory '/<>/builddir'
make[3]: *** [CMakeFiles/Makefile2:7909:
storage/rocksdb/CMakeFiles/sst_dump.dir/all] Error 2
make[3]: *** Waiting for unfinished jobs


The new .24 failed on Debian builders now with:

https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.24-1=1598114515=0

cd /<>/builddir/storage/spider &&
/usr/bin/riscv64-linux-gnu-g++  -DDBUG_TRACE -DHAVE_CONFIG_H
-DMYSQL_DYNAMIC_PLUGIN -D_FILE_OFFSET_BITS=64 -Dspider_EXPORTS
-I/<>/builddir/include
-I/<>/storage/spider/hs_client -I/<>/include
-I/<>/sql -I/<>/extra/yassl/include
-I/<>/extra/yassl/taocrypt/include  -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pie
-fPIC -fstack-protector --param=ssp-buffer-size=4 -fno-rtti
-DHAVE_HANDLERSOCKET -O2 -g -static-libgcc -fno-omit-frame-pointer
-fno-strict-aliasing -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF
-Wall -Wextra -Wformat-security -Wno-format-truncation -Wno-init-self
-Wno-nonnull-compare -Wno-unused-parameter -Woverloaded-virtual
-Wnon-virtual-dtor -Wvla -Wwrite-strings -fPIC   -Wdate-time
-D_FORTIFY_SOURCE=2 -o CMakeFiles/spider.dir/spd_db_conn.cc.o -c
/<>/storage/spider/spd_db_conn.cc
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function
`rocksdb::ConcurrentArena::ApproximateMemoryUsage() const':

Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-30 Thread Otto Kekäläinen
Thanks for looking into this!

I would appreciate is some risc expert tested the solution on a risc
builder and eventually filed a MR at
https://salsa.debian.org/mariadb-team/mariadb-10.3 or directly upstream at
github.com/mariadb/server. Filing a PR upstream would be the guaranteed way
to get a RocksDB/atomic expert to review/comment the issue.


- Otto


Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-28 Thread Aurelien Jarno
Hi,

On 2019-07-26 22:17, Otto Kekäläinen wrote:
> Package: mariadb-10.3
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> 
> The version of the package currently FTBFS on the riscv64 port.
> 
> From 
> https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0
> 
> 
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> /usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
> more undefined references to `__atomic_compare_exchange_1' follow
> collect2: error: ld returned 1 exit status
> 
> If you are an RISC expert, feel free to fork
> https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
> make a merge request.

The problem is that RISC-V only provides 4- and 8-byte atomic
instructions, so 1-byte atomic support has to be emulated by libatomic.
There is code for that in the rocksdb build system (however it probably
needs to be patch for riscv64), but it looks like more complex to do in
the mariadb build system.

Note that the issue likely affects some 32-bit architectures that do not
have 8-byte atomic instructions, however rocksdb support is disabled by
default for 32-bit architectures. It's also the strategy we have used
for the version we currently have in unreleased [1]. Here is the
corresponding patch:


diff -Nru mariadb-10.3-10.3.16/debian/rules mariadb-10.3-10.3.16/debian/rules
--- mariadb-10.3-10.3.16/debian/rules   2019-06-19 21:28:52.0 +0200
+++ mariadb-10.3-10.3.16/debian/rules   2019-07-23 17:48:12.0 +0200
@@ -47,6 +47,11 @@
 CMAKEFLAGS += -DWITHOUT_ROCKSDB=true
 endif
 
+# Skip RocksDB on riscv64, as it requires fixes wrt libatomic
+ifeq ($(DEB_HOST_ARCH),riscv64)
+CMAKEFLAGS += -DWITHOUT_ROCKSDB=true
+endif
+
 # Skip TokuDB if arch is not amd64 (also disable for kfreebsd-amd64 as it 
FTBFS)
 # Skipped on the x32 ABI too; untested, but unlikely to work given i386 is not
 # supported.


I don't know if it is something you want to merge in the package or if
you prefer to have a real fix with to the rocksdb support.

Aurelien

[1] http://ftp.ports.debian.org/debian-ports/pool-riscv64/main/m/mariadb-10.3/

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-28 Thread Héctor Orón Martínez
Hello,

Missatge de Hector Oron  del dia dg., 28 de jul.
2019 a les 1:45:
> The code including atomic must link using `-latomic`, that is
> apparently GCC bug, which it is not often seen in other architectures.
> I have been unable to test the assumption.

>From irc://OFTC/debian-riscv channel someone suggests to link -pthread.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-27 Thread Hector Oron
Hello,

Missatge de Otto Kekäläinen  del dia ds., 27 de jul.
2019 a les 3:21:
>
> Package: mariadb-10.3
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
>
> The version of the package currently FTBFS on the riscv64 port.
>
> >From 
> >https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0
>
>
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> /usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
> more undefined references to `__atomic_compare_exchange_1' follow
> collect2: error: ld returned 1 exit status
>
> If you are an RISC expert, feel free to fork
> https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
> make a merge request.

According to:
https://github.com/riscv/riscv-gnu-toolchain/issues/183#issuecomment-253721765

The code including atomic must link using `-latomic`, that is
apparently GCC bug, which it is not often seen in other architectures.
I have been unable to test the assumption.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.



Bug#933151: mariadb-10.3: FTBFS on riscv64

2019-07-26 Thread Otto Kekäläinen
Package: mariadb-10.3
X-Debbugs-CC: debian-ri...@lists.debian.org
User: debian-ri...@lists.debian.org
Usertags: riscv64

The version of the package currently FTBFS on the riscv64 port.

>From 
>https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0


/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
undefined reference to `__atomic_fetch_or_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
undefined reference to `__atomic_fetch_or_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
undefined reference to `__atomic_compare_exchange_1'
/usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
/usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
`__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
reference to `__atomic_compare_exchange_1'
/usr/bin/ld: 
librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
more undefined references to `__atomic_compare_exchange_1' follow
collect2: error: ld returned 1 exit status

If you are an RISC expert, feel free to fork
https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
make a merge request.

Thanks,

Otto