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:
include(lcfg.cmake)
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:
include(FindTCL)
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 /bin/tclsh
.
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 tclsh
.
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)
Whether 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.