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

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.5.30
    • Fix Version/s: 5.5.31
    • Component/s: None
    • Labels:
      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.

        Gliffy Diagrams

          Attachments

            Activity

            Hide
            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.

            Show
            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.
            Hide
            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

            Show
            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

              • Assignee:
                wlad Vladislav Vaintroub
                Reporter:
                knielsen Kristian Nielsen
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour, 30 minutes
                  1h 30m