Details
Description
the problem appears during MaxScale build attempt for Fedora 19/20:
In file included from /usr/include/mysql/private/probes_mysql.h:22:0,
|
from /usr/include/mysql/private/sql_class.h:38,
|
from query_classifier.cc:45:
|
/usr/include/mysql/private/probes_mysql_dtrace.h:9:21: fatal error: sys/sdt.h: No such file or directory
|
#include <sys/sdt.h>
|
^
|
The problem can be solved by installing "systemtap-sdt-devel" package.
The probes_mysql.h header file has the following content:
#if defined(HAVE_DTRACE) && !defined(DISABLE_DTRACE)
|
#include "probes_mysql_dtrace.h"
|
#else /* no dtrace */
|
#include "probes_mysql_nodtrace.h"
|
#endif
|
it looks like HAVE_DTRACE is defined during MariaDB build and "probes_mysql_dtrace.h" is included into the build, but dependency on "systemtap-sdt-devel" is not set and "systemtap-sdt-devel" is not installed when mariadb-devel is installed.
It is possible the same happens in CentOS 7, but can't test now due to lack of libmysqld.a in CentOS7 packages.
Just as described.
In this case we probably just need to remove dtrace-containing packages from the build machines – why would we need them there?
But in general, I've also had a similar problem in past building the server itself. My machine had dtrace itself, but apparently didn't have the headers or something.
I don't see why dtrace has to be enabled as soon as it's found; we don't enable valgrind in a build just because it exists in the system. I think ENABLE_DTRACE should be set explicitly, otherwise it should be considered disabled, even if dtrace exists.