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

out-of-tree build from source tarball wrongly copies sql/sql_yacc.cc from source even if sql_yacc.yy is newer

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.5.30
    • 5.5.31
    • None
    • None

    Description

      I have seen a couple of distros (Arch, Debian) having problems when patching
      sql/sql_yacc.yy. The problem is that the build does not regenerate
      sql/sql_yacc.cc with bison, instead it copies the stale sql_yacc.cc from the
      source dir.

      This occurs with out-of-tree build, not sure with in-tree build.

      Probably this code in sql/CMakeLists.txt is responsible, it does not seem to
      take into account that the .yy file may be newer:

      # Handle out-of-source build from source package with possibly broken 
      # bison. Copy bison output to from source to build directory, if not already 
      # there
      IF (NOT ${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
        IF(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/sql_yacc.cc)
          IF(NOT EXISTS ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc)
            CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/sql_yacc.cc 
              ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.cc COPYONLY)
            CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/sql_yacc.h
              ${CMAKE_CURRENT_BINARY_DIR}/sql_yacc.h COPYONLY)
          ENDIF()
        ENDIF()
      ENDIF()

      My suggestion would be to just remove that. If people do out-of-tree build,
      they need to have bison installed, no big deal. Better than getting wrong code
      generated due to changes to sql/sql_yacc.yy not getting picked up.

      Attachments

        Activity

          Just to clarify: The problem here is the following:

          1. Unpack the source tarball
          2. Modify sql/sql_yacc.yy in the source tree
          3. Build out-of-tree (I do not know if in-tree has the same problem)
          4. The build uses the sql_yacc.cc from the source tarball, discarding the changes from (2)

          This was seen in Debian and Arch, when they applied a patch for a security fix. The security fix was thus lost, and this was only detected because those distros run the test suite and noticed the failure.

          knielsen Kristian Nielsen added a comment - Just to clarify: The problem here is the following: 1. Unpack the source tarball 2. Modify sql/sql_yacc.yy in the source tree 3. Build out-of-tree (I do not know if in-tree has the same problem) 4. The build uses the sql_yacc.cc from the source tarball, discarding the changes from (2) This was seen in Debian and Arch, when they applied a patch for a security fix. The security fix was thus lost, and this was only detected because those distros run the test suite and noticed the failure.

          Ok, I changed not to copy into builddir in out-of-source build, in case usable bison is installed on the machine.

          To the proposal "If people do out-of-tree build, they need to have bison installed" - I personally do not mind generally requiring bison for the build. However I would not be happy with different handling in in-source or out-of-source cases (i.e if we require bison, then in all cases, and we stop distributing sql_yacc.cc and sql_yacc.h) . I've spent quite a lot of time to make out-of-source work just like in-source, and see any deviation as a bug since then

          wlad Vladislav Vaintroub added a comment - Ok, I changed not to copy into builddir in out-of-source build, in case usable bison is installed on the machine. To the proposal "If people do out-of-tree build, they need to have bison installed" - I personally do not mind generally requiring bison for the build. However I would not be happy with different handling in in-source or out-of-source cases (i.e if we require bison, then in all cases, and we stop distributing sql_yacc.cc and sql_yacc.h) . I've spent quite a lot of time to make out-of-source work just like in-source, and see any deviation as a bug since then

          People

            wlad Vladislav Vaintroub
            knielsen Kristian Nielsen
            Votes:
            0 Vote for this issue
            Watchers:
            2 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.