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
- All
- Comments
- Work Log
- History
- Activity
- Transitions
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.