Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-6746

Fedora packages built with 'HAVE_DTRACE' option, but there is no dpendecy on systemtap-sdt packages

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.

      Attachments

        Activity

          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.

          elenst Elena Stepanova added a comment - 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.

          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.

          serg Sergei Golubchik added a comment - 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.

          People

            serg Sergei Golubchik
            tturenko Timofey Turenko
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.