For comparison, TokuDB (which also needs a C++11 compiler) is present in these bintars:

./mariadb-10.2.12-linux-systemd-x86_64/lib/plugin/ha_tokudb.so

./mariadb-10.2.12-linux-glibc_214-x86_64/lib/plugin/ha_tokudb.so

Looking at buildbot logs for making bintars:

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-quantal-amd64/builds/9046/steps/compile/logs/stdio

-- Check if the system is big endian - little endian

-- Can't build rocksdb engine - requires c++11 -capable compiler (minimal supported versions are g++ 4.8, clang 3.3, VS2015)

-- Performing Test TOKUDB_OK

-- Performing Test TOKUDB_OK - Success

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-centos5-amd64/builds/8389/steps/compile/logs/stdio

-- Check if the system is big endian - little endian

-- Can't build rocksdb engine - requires c++11 -capable compiler (minimal supported versions are g++ 4.8, clang 3.3, VS2015)

-- CMake 2.8.9 or higher is required by TokuDB

http://buildbot.askmonty.org/buildbot/builders/kvm-bintar-trusty-amd64/builds/4476/steps/compile/logs/stdio

( builds both MyRocks and TokuDB)

Apparently, something went wrong with MDEV-9734.

Initially, trusty builder was meant to be a replacement for the EOL-ed quantal, to build glbc 2.14+ binaries and (as requested in MDEV-9734) also provide systemd support, which quantal couldn't do. Quantal bintars were at that point kept just in case, for compatibility purposes etc. Trusty was never intended to support some "older version of systemd", if it does, it's a mistake which probably needs to be fixed.

For the quantal builder which doesn't build MyRocks, that's because it has gcc 4.7.2; I don't think it makes sense to upgrade it, it the builder needs to be replaced anyway.

This is two issues, the "systemd bintar only works on systems running old systemd" issue should be moved to a new MDEV. I think the solution to it is to create a new systemd bintar builder, based on our CentOS 7.x or Ubuntu Xenial builders, whichever one would work best for creating bintars with systemd stuff in them.

In regards to MyRocks not being built by our CentOS 5 and Quantal bintar builders, I'm not sure we should update them so that MyRocks can be built.

On our CentOS 5 builder we don't build TokuDB and I don't think we should build MyRocks either. This isn't because of TokuDB, rather because of the the builder. serg looked into getting TokuDB working on the CentOS 5 builder (MDEV-5731) but the version of glibc on CentOS 5 is a roadblock. My guess is the same issues encountered with TokuDB would happen with MyRocks, and possibly more.

As far as the Quantal (glibc_214) builder is concerned, I could install a manually-compiled custom updated toolchain on it, but I don't want to do that unless it is something we really need. Ideally I'd like to get rid of the Quantal builder entirely and not try to keep it propped up with custom fixes. It probably should have been retired a while ago (the same can probably be said for the CentOS 5 builder).

As of 10.2.32, the bintar-linux-glibc_214-x86_64 now has MyRocks.

As of 10.3.23 and 10.4.13, both the bintar-linux-glibc_214-x86_64 and bintar-linux-x86_64 bintars have MyRocks.