MantisBT - CMake
View Issue Details
0010707CMakeCMakepublic2010-05-12 08:232016-06-10 14:31
Sam Bromley 
Bill Hoffman 
normalmajoralways
closedmoved 
CMake-2-8 
 
0010707: Error running cmake::LoadCache(). Aborting (See /Bug/view.php?id=6114)
Pulled from the latest cmake git repository. Built tags v2.8.0, v2.8.1, and the latest
nightly (87dbbf9cbe1039ae370edbe19b825c6b596ece95). Each builds fine, but once new
version is installed, ccmake fails with:
Error running cmake::LoadCache(). Aborting
This is the same as Issue#0006114, which was closed (2007) due to unreproducibility.
Ubuntu 10.04, CPU i7.

Any insight greatly appreciated.
I'll help in any way I can.
No tags attached.
Issue History
2010-05-12 08:23Sam BromleyNew Issue
2010-05-12 08:36Bill HoffmanNote Added: 0020720
2010-05-12 09:11Sam BromleyNote Added: 0020721
2010-05-12 09:12Sam BromleyNote Edited: 0020721
2010-05-12 09:28Bill HoffmanNote Added: 0020722
2010-05-12 09:28Bill HoffmanStatusnew => assigned
2010-05-12 09:28Bill HoffmanAssigned To => Bill Hoffman
2010-05-12 09:41Sam BromleyNote Added: 0020723
2010-05-12 12:12Bill HoffmanNote Added: 0020724
2016-06-10 14:28Kitware RobotNote Added: 0041695
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0020720)
Bill Hoffman   
2010-05-12 08:36   
Can you build debug, then run in gdb?

If so, put a break point in cmake::LoadCache() and find out what is going wrong.
(0020721)
Sam Bromley   
2010-05-12 09:11   
(edited on: 2010-05-12 09:12)
Hmm, actually running in gdb works fine. That is, if I do
gdb ccmake
% set args ..
% run
Then everything works. Running in valgrind works too.
But running bare dies.

Ok. I know what is happening. The new cmake build is installed in /usr/local/bin.
Which shows up first in my path (good). But when I run ccmake bare, it tries to use /usr/bin/cmake (the cmake used to build the new cmake). A difference in versions seems to be causing the issue. If I rename /usr/bin/cmake to /usr/bin/cmake.orig, and re-run the new ccmake, it seems to find the new cmake in /usr/local/bin and is happy.

Why it finds the new /usr/local/bin/cmake when under gdb and valgrind, but not when bare is a bit odd. When building the entire package, is there a way for the internally stored path to the new cmake to be set to the one about to be built?

(0020722)
Bill Hoffman   
2010-05-12 09:28   
Might be in here:

void cmSystemTools::FindExecutableDirectory(const char* argv0)


Are there any other error messages? ccmake >& out
What is in out? Is it finding cmake or ccmake? What if you use a full path to ccmake?
(0020723)
Sam Bromley   
2010-05-12 09:41   
There are no additional error messages.
The correct (new) ccmake is being run (and using the
full path doesn't change the outcome.)
If I edit the CMakeCache.txt file and replace /usr/local/bin/cmake with
/usr/bin/cmake, the error occurs.
If I start from scratch with a clean build directory (no cache),
and if /usr/bin/cmake is in my path, /usr/local/bin/ccmake attempts
to use that first, rather than /usr/local/bin/cmake which is later
in my path. Does the possibility exist to have ccmake attempt to
execute an internally defined default path to cmake (the installed dir),
or would this be too much of a violation of the Unix way?

I guess ultimately the issue is more of a configuration one. A warning
of mismatched paths to the executables may be valuable here.
(0020724)
Bill Hoffman   
2010-05-12 12:12   
I am trying to figure out what path the code takes when this happens.

Error is here:
 if(this->LoadCache() < 0)
      {
      cmSystemTools::Error("Error executing cmake::LoadCache(). Aborting.\n");
      return -1;
      }

So, LoadCache must be returning non 0.

Which I am guessing fails in this part:

  if(!this->AddCMakePaths())
    {
    return -3;
    }

So, the problem must be in AddCMakePaths. Can you try and figure out where in AddCMakePaths it is going wrong?
(0041695)
Kitware Robot   
2016-06-10 14:28   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.