After upgrade, the machine has gcc 4.9.0 which is known not to work well for MariaDB anyway (see MDEV-6340).

See also MDEV-6446

We found the same problem was hit by the Arch packagers. I believe the problem is a combination of -flto in gcc 4.9.x generating object files that can't be handled by normal ar/nm/ranlib (gcc now ships gcc-ar/gcc-nm/gcc-ranlib wrappers), and TokuDB's usage of ar/ranlib to merge static libraries before finally linking ha_tokudb.so. The solution we found in Arch was to set -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_RANLIB=/usr/bin/gcc-ranlib.

I think the real solution is to include something like the following in some higher-level cmake, before we get down to the storage engine's cmake files (taken from https://github.com/Tokutek/ft-index/blob/ed02cc90b2c3d723f41e745811daea7182ef5407/CMakeLists.txt#L10-L33)

## Versions of gcc >= 4.9.0 require special version of 'ar' and 'ranlib' for

## link-time optimizations to work properly.

##

## From https://gcc.gnu.org/gcc-4.9/changes.html:

##

##     When using a linker plugin, compiling with the -flto option now

##     generates slim objects files (.o) which only contain intermediate

##     language representation for LTO. Use -ffat-lto-objects to create

##     files which contain additionally the object code. To generate

##     static libraries suitable for LTO processing, use gcc-ar and

##     gcc-ranlib; to list symbols from a slim object file use

##     gcc-nm. (Requires that ar, ranlib and nm have been compiled with

##     plugin support.)

if ((CMAKE_CXX_COMPILER_ID STREQUAL GNU) AND

    NOT (CMAKE_CXX_COMPILER_VERSION VERSION_LESS "4.9.0"))

  find_program(gcc_ar "gcc-ar")

  if (gcc_ar)

    set(CMAKE_AR "${gcc_ar}")

  endif ()

  find_program(gcc_ranlib "gcc-ranlib")

  if (gcc_ranlib)

    set(CMAKE_RANLIB "${gcc_ranlib}")

  endif ()

endif()

I tried to use the trick with

-DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_RANLIB=/usr/bin/gcc-ranlib

but it doesn't look to work, since /usr/bin/ar is still called when building xz library for ft-index and it crashes:

/usr/bin/ar terminated with signal 11 [Segmentation fault], core dumped

However, that pointed me on a different thing, that there is no option to use the lzma library from the system, the ft-index is always built with bundled one. IMHO, that should be fixed so system library is used by default and only when not available, the bundle one should be used.

About lzma — this was an intentional decision of tokudb developers. They decided to use a specific xz library version, saying that using later versions resulted in a notably lower performance.

Thanks for the info about xz; it seems like mariadb should respect that decision then. However, since it is far away from acceptable way for Fedora/Red Hat, especially regarding security, I'll try to talk to Tokutek directly to re-consider this way of solving such issues.

Thanks! Many distributions would appreciate that.

By the way, using gcc-ar and gcc-ranlib didn't help me either...

I've opened that question on the Google Group, no response yet:
https://groups.google.com/forum/#!search/tokudb-dev/tokudb-dev/FAUH3E5bV5c/1SwcsW0GxLgJ
Not sure if there is a better way to contact TokuDB developers; if it is, please, point me there.

It seems the root cause was TokuDB incompatibility with GCC 4.9, which seems to be fixed by commit https://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/0.34.5868 and is confirmed to work in build sid build #38 at http://buildbot.askmonty.org/buildbot/builders/debpkg-sid/builds/38/steps/compile/logs/stdio, so this is issue is now resolved.

Well, I still see the same issue with gcc-4.9.1-5.fc22.x86_64 and mariadb-10.0.13 on Fedora rawhide (22). And I don't see an option to re-open this bug, maybe I'm just blind – could we re-open it, please?

reopened on request by Honza, see comment below

TokuDB 7.5.0 compiles just fine for me on debian sid with the latest gcc 4.9.1 that sid has.

It still does not build on Fedora, but it seems to be issue in Fedora's ar, which crashes, reported as:
https://bugzilla.redhat.com/show_bug.cgi?id=1149660

Ok, thanks. I've added myself to the CC of that bug, if there'll be something we need to do — hopefully I'll see it.