There’s a problem with Tcl’s CMake scripts on SL7.
We use CMake to build our LCFG packages, as documented at LCFG Build Tools. The CMake configuration for a package is held in its
CMakeLists.txt file. This mostly just pulls in our standard LCFG build environment:
but it can also be used to tweak or add things to the CMake configuration. A package which uses the Tcl scripting language would use
CMakeLists.txt to pull in some Tcl configuration:
This is the standard way of asking CMake to deduce where various Tcl bits and pieces are and fill in correct values for Tcl-related CMake variables.
We’ve found that it’s filling in the wrong value for the @TCL_TCLSH@ variable. On SL7 this should evaluate to
/usr/bin/tclsh, but it actually evaluates to
For a user or for a script this isn’t really a problem, because
/bin on SL7 is a symbolic link to
/usr/bin, so either path will find
However for an RPM package to be built with a requirement for
/bin/tclsh certainly is a problem, because such a requirement is unfulfillable. The
tcl package provides
/usr/bin/tclsh, and no package at all provides
/bin/tclsh, so the package building software doesn’t have any way of figuring out how to fulfil the requirement for
/bin/tclsh. All it knows is that it doesn’t know of a package which provides
/bin/tclsh – so when we try to install a package which requires Tcl, the unfulfilled requirement is flagged as an error.
I haven’t found a fix for this, but here’s a workaround: simply edit
CMakeLists.txt to set the variable to its correct value:
set(TCL_TCLSH "/usr/bin/tclsh") include(lcfg.cmake)
include(FindTCL) is then left in or removed, the @TCL_TCLSH@ variable is correctly expanded to
/usr/bin/tclsh, and the bogus requirement for
/bin/tclsh disappears; so the resulting package is installable on SL7.