(0020720)
Bill Hoffman (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
2010-05-12 08:23	Sam Bromley	New Issue
2010-05-12 08:36	Bill Hoffman	Note Added: 0020720
2010-05-12 09:11	Sam Bromley	Note Added: 0020721
2010-05-12 09:12	Sam Bromley	Note Edited: 0020721
2010-05-12 09:28	Bill Hoffman	Note Added: 0020722
2010-05-12 09:28	Bill Hoffman	Status	new => assigned
2010-05-12 09:28	Bill Hoffman	Assigned To	=> Bill Hoffman
2010-05-12 09:41	Sam Bromley	Note Added: 0020723
2010-05-12 12:12	Bill Hoffman	Note Added: 0020724
2016-06-10 14:28	Kitware Robot	Note Added: 0041695
2016-06-10 14:28	Kitware Robot	Status	assigned => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Notes
(0020720) Bill Hoffman (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (administrator) 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.

Relationships