[CMake] CMAKE_LIBRARY_PATH appears not to work properly for finding libtcl

Alan W. Irwin irwin at beluga.phys.uvic.ca
Thu May 13 00:09:04 EDT 2010


A PLplot developer who is not that familiar with CMake has just reported
that CMAKE_LIBRARY_PATH does not allow him to find the libtcl8.4.so library
that he had built and installed in a special location.

The relevant fragment of code in FindTCL.cmake is the following:

FIND_LIBRARY(TCL_LIBRARY
   NAMES
   tcl
   tcl${TK_LIBRARY_VERSION} tcl${TCL_TCLSH_VERSION} tcl${TK_WISH_VERSION}
   tcl86 tcl8.6
   tcl85 tcl8.5
   tcl84 tcl8.4
   tcl83 tcl8.3
   tcl82 tcl8.2
   tcl80 tcl8.0
   PATHS ${TCLTK_POSSIBLE_LIB_PATHS}
   )

The result he obtains with cmake-2.8.1 built from source is cmake finds his
system version (/usr/lib64/libtcl.so) rather than the desired
$CMAKE_LIBRARY_PATH/libtcl8.4.so.

I always felt the effect of the above code fragment would be all NAMES
were searched for in the documented locations in order from
#1 (corresponds in part to the cmake CMAKE_LIBRARY_PATH option), #2
(corresponds in part to the CMAKE_LIBRARY_PATH environment variable)
,..., through #6 (corresponds in part to the PATHS specified above).  In
other words the NAMES are run through in the innermost loop and
the locations from #1 to #6 are handled in an outer loop so that libtcl8.4.so
pointed to by CMAKE_LIBRARY_PATH would be found.

However, from the result reported to me, it appears the inner and outer
loops are switched from what I thought so libtcl.so is always found
preferentially if present in the system location regardless of
CMAKE_LIBRARY_PATH.

Is that right?  Or is something else going on?

Whatever the cause of this, it seems a rather noxious bug to me if a
developer cannot use CMAKE_LIBRARY_PATH to find libtcl8.4.so in a
non-standard location because of a system version with name libtcl.so.

If the CMake developers also feel this is a strange result and therefore
need more detailed results to help diagnose this, I will try to make a
simplest possible example that anybody can run that shows the issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________


More information about the CMake mailing list