Details
Major
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.
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
This is not a bug. Our public API headers don't depend on dtrace. If you're using headers from private/ — you're on your own, no promises.
But even in that case there is a simple workaround, define DISABLE_DTRACE in your code or pass it to the compiler on the command line.
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.