Bug 250714

Summary: databases/mariadb104-server: enable galera/wsrep on arm64/aarch64
Product: Ports & Packages Reporter: Vincent Milum Jr <freebsd>
Component: Individual Port(s)Assignee: Bernard Spil <brnrd>
Status: Closed FIXED    
Severity: Affects Only Me CC: mikael
Priority: --- Flags: bugzilla: maintainer-feedback? (brnrd)
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250664

Description Vincent Milum Jr 2020-10-29 07:25:09 UTC
Related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250664

The databases/galera26 port is being updated to support ARM64/Aarch64. MariaDB already supports this, except the wsrep_ shell scripts are being excluded in the Makefile from aarch64 targets.

Using the updated galera package along with just copying in these shell scripts from an amd64 machine, galera cluster support is up and working just fine on my arm64 test cluster.

From the Makefile. This just needs extending to support arm64:

.if ${ARCH} != amd64
PLIST_SUB+= WSREP="@comment "
.endif
Comment 1 Mikael Urankar freebsd_committer freebsd_triage 2020-10-29 20:42:19 UTC
I tried to build the wsrep bits on aarch64 and it builds fine, why is it limited to amd64?
Comment 2 Vincent Milum Jr 2020-10-29 21:48:03 UTC
(In reply to Mikael Urankar from comment #1)

Probably because Galera (databases/galera26) itself was limited to AMD64.

Also, MariaDB already compiles the wsrep in without these changes from ports on ARM64. The problem is the wsrep_ shell scripts are not being included in the package, that's it.

When I installed the pre-compiled package from pkg, and copied in just the wsrep_ shell scripts, all worked perfectly (after custom building the databases/galera26 package)
Comment 3 Mikael Urankar freebsd_committer freebsd_triage 2020-10-30 07:26:25 UTC
(In reply to Vincent Milum Jr from comment #2)
There is a WSREP option that sets / unsets WSREP_CMAKE_BOOL.
Also, galera26 builds fine on powerpc64, this WSREP OPTIONS looks plain wrong.
Comment 4 Bernard Spil freebsd_committer freebsd_triage 2020-11-07 17:30:37 UTC
(In reply to Vincent Milum Jr from comment #0)

Are you saying that we should treat aarch64 like amd64 in relation to Galera/WSREP?
Comment 5 Bernard Spil freebsd_committer freebsd_triage 2020-11-07 17:32:48 UTC
@Vincent

Does this fix the issue for you?

@@ -58,6 +58,7 @@
 OPTIONS_GROUP=         COMPRESSION ENGINES GROONGA
 OPTIONS_DEFINE=                CONNECT_EXTRA DOCS
 OPTIONS_DEFINE_amd64=  WSREP
+OPTIONS_DEFINE_aarch64=        WSREP
 OPTIONS_GROUP_COMPRESSION=     LZ4 LZO SNAPPY ZSTD
 OPTIONS_GROUP_ENGINES= COLUMNSTORE INNOBASE MROONGA OQGRAPH ROCKSDB S3 SPHINX SPIDER
 OPTIONS_GROUP_GROONGA= ZMQ MSGPACK
@@ -210,7 +211,7 @@
 GSSAPI_BASE_IGNORE=    GSSAPI_BASE is not compatible with OpenSSL from ports. Use other GSSAPI options or OpenSSL from base system
 .endif
 
-.if ${ARCH} != amd64
+.if ${ARCH} != amd64 && ${ARCH} != aarch64
 PLIST_SUB+=    WSREP="@comment "
 .endif
Comment 6 Vincent Milum Jr 2020-11-07 17:36:33 UTC
(In reply to Bernard Spil from comment #4)

Correct! Galera works just fine in Aarch64, I've been running it for almost 2 weeks now.

And from a quick visual inspection, the diff looks good. I'll go ahead and apply it locally to test a little later today to verify.
Comment 7 Bernard Spil freebsd_committer freebsd_triage 2020-11-07 18:40:02 UTC
Hmmm. Can't really release this until the galera26 port removes the

> BROKEN_aarch64=         fails to compile: gu_int128.h: use of undeclared identifier '__bswap64_var'

https://svnweb.freebsd.org/ports/head/databases/galera26/Makefile?revision=553433&view=markup
Comment 8 Vincent Milum Jr 2020-11-07 19:15:02 UTC
(In reply to Bernard Spil from comment #7)

There is already an open bug for that (linked above), which on that bug requested this bug to be opened.

And IMO, I don't think we should even have the AMD64/Aarch64 check at all for WSREP on the MariaDB ports themselves. That check has no effect on the actual C/C++ compilation. All it does is either include or exclude a handful of shell scripts, of which don't depend on any arch anyways.

Not having that check means that as upstream development continues on other platforms (such as RISC-V), we won't have to have this same discussion in the future about what platforms is/isnt supported, because they're just platform independent shell scripts.
Comment 9 Mikael Urankar freebsd_committer freebsd_triage 2020-11-09 16:00:48 UTC
(In reply to Bernard Spil from comment #7)
fixed in ports r554729