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.