[MDEV-6746] Fedora packages built with 'HAVE_DTRACE' option, but there is no dpendecy on systemtap-sdt packages Created: 2014-09-16  Updated: 2014-10-02  Resolved: 2014-10-02

Status: Closed
Project: MariaDB Server
Component/s: OTHER
Affects Version/s: 5.5.39, 10.0.14
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Timofey Turenko Assignee: Sergei Golubchik
Resolution: Not a Bug Votes: 0
Labels: buildbot, compile, packaging


 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.

 Comments   
Comment by Elena Stepanova [ 2014-09-22 ]

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.

Comment by Sergei Golubchik [ 2014-10-02 ]

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.

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