[MDEV-14537] TokuDB not recognized for compilation Created: 2017-11-29  Updated: 2017-11-30  Resolved: 2017-11-30

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 10.2.11
Fix Version/s: 10.2.11

Type: Bug Priority: Blocker
Reporter: Michal Schorm Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

Fedora Rawhide

Issue Links:
Relates
relates to MDEV-14524 TokuDB is unable to be built on Linux Closed

 Description   

Hello, I tried to pack the new 10.2.11 into Fedora.

Everything's fine but TokuDB, which won't compile anymore.
The Cmake won't recognize it as usable: "Performing Test TOKUDB_OK - Failed"

I think the issue lies within this commit: 7f1900705b
https://github.com/MariaDB/server/commit/7f1900705b
Within file "storage/tokudb/CMakeLists.txt"

The new code there is:

# tokudb requires F_NOCACHE, O_DIRECT, and designated initializers
 
CHECK_CXX_SOURCE_COMPILES(
 
"
 
#include <fcntl.h>
 
struct a {int b; int c; };
 
struct a d = { .b=1, .c=2 };
 
int main() { return F_NOCACHE + O_DIRECT; }
 
" TOKUDB_OK)

While the 'O_DIRECT' can be set

 The O_DIRECT, O_NOATIME, O_PATH, and  O_TMPFILE  flags  are  Linux-spe‐cific. One must define _GNU_SOURCE to obtain their definitions

The 'F_NOCACHE' is Darwin Kernel (Mac OS X) specific and not present in Fedora.

 Comments   
Comment by Sergei Golubchik [ 2017-11-29 ]

Yes, we're fixing the source and releasing missing packages.

As a workaround you can specify -DTOKUDB_OK=1 in a .spec file.

Comment by Michal Schorm [ 2017-11-29 ]

Added "-DTOKUDB_OK=1" as a Cmake argument, eneded up with "lto1: internal compiler error: Segmentation fault".

Probabbly not something you should take care of , just informing. (In case more people would hit it)
I'll try to look into it.

Comment by Michal Schorm [ 2017-11-30 ]

The compiler error meantioned in previous comment is most likely some Fedora Rawhide issue.
On released Fedora 27 it builds fine when using your workaround.

Generated at Thu Feb 08 08:14:21 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.