Bug 247535

Summary: databases/mariadb105-{server,client} - 10.5.4 is the first stable release in the MariaDB 10.5 series
Product: Ports & Packages Reporter: VVD <vvd>
Component: Individual Port(s)Assignee: Bernard Spil <brnrd>
Status: Closed FIXED    
Severity: Affects Many People CC: alex, brnrd, cyberbotx, peter, r.quakkelaar
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   
URL: https://mariadb.org/mariadb-10-5-4-now-available

Description VVD 2020-06-25 11:06:02 UTC
MariaDB 10.5.4 now available - 2020-06-24
The MariaDB Foundation is pleased to announce the availability of MariaDB 10.5.4, the first stable release in the MariaDB 10.5 series.

* Notable Changes
This is the first Stable (GA) release in the MariaDB 10.5 series.
    - This release of MariaDB Server includes the S3 storage engine. Note, that plugins have independent maturity levels and S3 storage engine in 10.5.4 has Alpha maturity.
    - This release of MariaDB Server includes the MariaDB ColumnStore storage engine. Note, that plugins have independent maturity levels and MariaDB ColumnStore in 10.5.4 has Beta maturity.
    - DROP TABLE now reliably deletes table remnants inside a storage engine even if the .frm file is missing.
    - Accelerated crc32() function for AMD64, ARMv8, POWER 8 (MDEV-22669).
    - Lots of bug fixes, see the changelog.

* Variables
    - Limit innodb_encryption_threads to 255 (MDEV-22258).
    - Minimum value of max_sort_length raised to 8 (previously 4) so fixed size data types like DOUBLE and BIGINT are not truncated for lower values of max_sort_length (MDEV-22715).

* InnoDB
    - DROP TABLE improvements: MDEV-8069, MDEV-11412, MDEV-22456.
    - InnoDB Performance improvements: MDEV-15053, MDEV-22593, MDEV-22697, MDEV-22871, MDEV-22841.
Comment 1 Bernard Spil freebsd_committer 2020-06-25 11:18:28 UTC
Port creation is already in progress. 
 * Default options work.
 * S3 and ColumnStore engines won't configure (cmake)
 * other options broken (cmake)

No clue why, but cmake is fighting me every step of the way!
Comment 2 Bernard Spil freebsd_committer 2020-06-25 11:19:50 UTC
You can check progress here
Comment 3 VVD 2020-06-25 11:29:04 UTC
Thanks for information!
Comment 4 commit-hook freebsd_committer 2020-07-11 20:17:38 UTC
A commit references this bug:

Author: brnrd
Date: Sat Jul 11 20:17:12 UTC 2020
New revision: 542046
URL: https://svnweb.freebsd.org/changeset/ports/542046

  databases/mariadb105-server: New port MariaDB 10.5

  PR:		247535
  Reported by:	VVD <vvd unislabs com>

Comment 5 VVD 2020-07-12 02:48:01 UTC
(In reply to commit-hook from comment #4)
It's broken on clean install - for example it doesn't create user and group mysql during install.
It need patch same as for 10.4:
Comment 6 commit-hook freebsd_committer 2020-07-12 20:17:25 UTC
A commit references this bug:

Author: brnrd
Date: Sun Jul 12 20:16:53 UTC 2020
New revision: 542103
URL: https://svnweb.freebsd.org/changeset/ports/542103

  databases/mariadb105-server: Unbreak runtime

   * Align with mariadb104-server
   * PID must be in mysql owned dir

  PR:		247535
  Reported by:	VVD <vvd unislabs com>

Comment 7 VVD 2020-07-13 02:55:15 UTC
(In reply to commit-hook from comment #6)
If you keep:
in databases/mariadb105-client/pkg-plist, then you need
in the client section of the if/else too, or in the both section before the if/else.
Comment 8 Naram Qashat 2020-07-13 16:12:58 UTC
I just attempted to build databases/mariadb105-server in poudriere on an amd64 machine with GSSAPI_BASE disabled and GSSAPI_MIT enabled, the build fails as such:

[00:18:30] [1158/1977] /usr/bin/c++  -DDBUG_TRACE -DHAVE_CONFIG_H -DMYSQL_DYNAMIC_PLUGIN -DPLUGIN_GSSAPI -Dauth_gssapi_EXPORTS -Iinclude -Isql -O2 -pipe -L/usr/local/lib -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include -O2 -pipe -L/usr/local/lib -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include -DDBUG_OFF -fPIC   -isystem /usr/local/include -std=gnu++11 -MD -MT plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o -MF plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o.d -o plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o -c plugin/auth_gssapi/gssapi_server.cc
[00:18:30] FAILED: plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o 
[00:18:30] /usr/bin/c++  -DDBUG_TRACE -DHAVE_CONFIG_H -DMYSQL_DYNAMIC_PLUGIN -DPLUGIN_GSSAPI -Dauth_gssapi_EXPORTS -Iinclude -Isql -O2 -pipe -L/usr/local/lib -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include -O2 -pipe -L/usr/local/lib -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -isystem /usr/local/include -DDBUG_OFF -fPIC   -isystem /usr/local/include -std=gnu++11 -MD -MT plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o -MF plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o.d -o plugin/auth_gssapi/CMakeFiles/auth_gssapi.dir/gssapi_server.cc.o -c plugin/auth_gssapi/gssapi_server.cc
[00:18:30] c++: warning: argument unused during compilation: '-L/usr/local/lib' [-Wunused-command-line-argument]
[00:18:30] c++: warning: argument unused during compilation: '-L/usr/local/lib' [-Wunused-command-line-argument]
[00:18:30] plugin/auth_gssapi/gssapi_server.cc:79:5: error: use of undeclared identifier 'krb5_xfree'
[00:18:30]     krb5_free_unparsed_name(context, unparsed_name);
[00:18:30]     ^
[00:18:30] plugin/auth_gssapi/gssapi_server.cc:34:38: note: expanded from macro 'krb5_free_unparsed_name'
[00:18:30] #define krb5_free_unparsed_name(a,b) krb5_xfree(b)
[00:18:30]                                      ^
[00:18:30] 1 error generated.
[00:18:30] ninja: build stopped: subcommand failed.
[00:18:30] *** Error code 1
[00:18:30] Stop.
[00:18:30] make: stopped in /usr/ports/databases/mariadb105-server

From extracting security/krb5 and checking its sources, there is no krb5_xfree in that port.

I'm honestly not sure why this is happening, looking at mariadb's source code for 10.5, the CMakeLists.txt for auth_gssapi should be checking for krb5_xfree in krb5.h and only set the HAVE_KRB5_XFREE definition is that is the case, but as can be seen in the above, there is no -DHAVE_KRB5_XFREE in the c++ invocation . To me this rules out that it is finding the definition of krb5_xfree in the base implementation.
Comment 9 Raymond Quakkelaar 2020-07-18 18:09:35 UTC
BROKEN_i386=	compile error: undeclared identifier 'my_atomic_add32'

It is possible to compile and run both MariaDB 10.5 and 10.4 on
FreeBBSD i386 (11.4) with GCC(8) by adding the following lines
to the makefile below USES=

CXXFLAGS+=	-fpermissive

Note 1: It is NOT sufficient to add -DUSE_NEW_READLINE_INTEFACE
in just the client section, although only there USES+=readline is applied
server compilation will fail when the switch is not globally present.

Note 2: I use GCC8 vs. current GCC9 for a problem with converters/wkhtmltopdf
but I do NOT suspect any problems there and perhaps someone can test if
this also works for clang 10...

Note 3: I had to move my.cnf one directory down to /usr/local/etc/mysql
otherwise it will not be used!
Comment 10 commit-hook freebsd_committer 2020-07-19 20:20:16 UTC
A commit references this bug:

Author: brnrd
Date: Sun Jul 19 20:19:55 UTC 2020
New revision: 542596
URL: https://svnweb.freebsd.org/changeset/ports/542596

  databases/mariadb105-server: Fix build for i386

   * pet portlint
   * i386 requires gcc [1]
   * Fix stacktrace [2]

  PR:		247535 [1], 247957 [2]
  Reported by:	 Raymond Quakkelaar <r quakkelaar quaras nl> [1], Naram Qashat <cyberbotx cyberbotx com> [2]

Comment 11 Bernard Spil freebsd_committer 2020-07-19 20:22:54 UTC
(In reply to Naram Qashat from comment #8)
Please open a new PR for the MIT Kerberos issue.
i386 build fixed with latest commit, thanks Raymond!
Comment 12 VVD 2020-07-20 07:44:52 UTC
(In reply to Bernard Spil from comment #11)
Bat what about broken clean install?

Do you want patch to current version of the port?
10.4 is still broken too…
Comment 13 Raymond Quakkelaar 2020-07-20 09:10:47 UTC
(In reply to VVD from comment #12)
Just to clarify.

I first "fixed" the 10.3 branch.
That is, it worked fine with clang10 and 8 on i386, but when i tried
compiling with GCC, I got the undeclared my_atomic_add64.
I think it was 64 not 32... It did already work with clang, mind you.

Then read about the common denominator my_atomic_add* theme and
and saw possibilities for a common fix.

And it works for: 10.3, 10.4 and 10.5 with GCC.

(Have NOT tried it with clang, but probably will also work considering
10.3 behaviour under clang and gcc)
Comment 14 Bernard Spil freebsd_committer 2020-07-24 18:33:11 UTC
(In reply to Raymond Quakkelaar from comment #13)
Hi Raymond,

I've tried 10.5 with these extra CFLAGS and CXXFLAGS, but the build fails unless I add USE_GCC. I'd happily add fixes for i386 but lack the time and resources to fully get this up-and-running. Can you provide svn diffs and poudriere build logs?
Separate PR's are OK for fixing the i386 build issue, closing this one.

Cheers, Bernard.
Comment 15 VVD 2020-07-25 07:19:32 UTC
I have one question only: how server can start after reboot if /var/run is tmpfs?
Comment 16 Raymond Quakkelaar 2020-07-25 17:26:33 UTC
(In reply to Bernard Spil from comment #14)
Hi Bernard,

I've had another look at this but can only compile with USE_GCC=yes.

But after having looked more closely at file include/my_atomic.h
it seems better to slightly change the flags in the makefile to:

.if ${ARCH} == i386
USE_GCC=	yes

The (purely GCC) -fpermissive is NOT needed, ergo there are NO dodgy constructs
in the code that need looking away from with fingers crossed...

It is preferable to drop -DHAVE_GCC_C11_ATOMICS and let the normal decision
tree take its course which favours -DHAVE_SOLARIS_ATOMICS following the excerpt
from include/my_atomic.h

  We choose implementation as follows: on Windows using Visual C++ the native
  implementation should be preferable. When using gcc we prefer the Solaris
  implementation before the gcc because of stability preference, we choose gcc
  builtins if available.

#if defined(_MSC_VER)
#include "atomic/generic-msvc.h"
#elif defined(HAVE_SOLARIS_ATOMIC)
#include "atomic/solaris.h"
#elif defined(HAVE_GCC_C11_ATOMICS)
#include "atomic/gcc_builtins.h"

As mentioned, have also tried various combinations with clang 10, but
without success. Perhaps someone knows the equivalent for -latomic in clang?
Comment 17 Raymond Quakkelaar 2020-07-26 01:03:22 UTC
(In reply to Bernard Spil from comment #14)
Hi Bernard,

Hmmmmm weird!

Suddenly 10.5 won't start anymore! I had to revert to 10.4!

To summarize:

Did a build of 10.5 with the slightly changed flags mentioned in my comment 16.
That build succeeded but I decided to restart later. Which failed.

Then rebuilt 10.5 with the original flags, which succeeded but failed
to start also.

This is my first completed build after the june 19 changes that were
applied as outlined in comment 10.
So it looks like there might be something in there that causes this.

Luckily, like I said earlier, I can compile and run 10.4 as well with the
same flags.
Comment 18 Raymond Quakkelaar 2020-07-26 08:59:41 UTC
(In reply to Raymond Quakkelaar from comment #17)
Looking at the diffs. of the JULY 19 changes, can there have gone something
wrong in the conversion from the mysql_install_db => mariadb-install-db
etc. combined with symlinks.

Because it really seems it literally does NOT start at all, like
a not found script that is silently skipped...
Comment 19 VVD 2020-07-26 10:58:35 UTC
(In reply to Raymond Quakkelaar from comment #18)
Check this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248186
Comment 20 Raymond Quakkelaar 2020-07-29 10:03:42 UTC
(In reply to VVD from comment #19)
Just to confirm.

I edited files/mysql-server.in and changed to "mariadbd-safe",
compiled with the flags from my comment 16 and it runs fine.

Hope you were not waiting for me...
Comment 21 VVD 2020-07-29 10:40:10 UTC
(In reply to Raymond Quakkelaar from comment #20)
Waiting Bernard to commit https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248186
Comment 22 Raymond Quakkelaar 2020-08-30 11:30:26 UTC
Just to confirm my findings as mentioned earlier in comment 16,

I can compile and run 10.5.5, just as 10.5.4, with just these flags:

.if ${ARCH} == i386
USE_GCC=	yes

Therefore -DHAVE_GCC_C11_ATOMICS and -fpermssive can be ditched!

Since that setup is less deviant from standard, it seems preferable.
Unless someone is experiencing problems with this???