[CMake] Target names now pollute namespace of filenames (was CMake 2.4.4 available for download)

[Alan W. Irwin]

On 2006-11-25 22:25-0500 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>> On 2006-11-25 11:02-0500 Bill Hoffman wrote:
>> 
>>> I have checked in a fix to cvs:
>>> 
>>> [...]Basically, support was added so that you could use a target name as 
>>> a DEPEND, but it was a bit
>>> loose on finding the targets.
>> 
>> This fix works for the small test example I gave with my bug report, but I
>> cannot definitively test it for PLplot because cmake CVS HEAD (as of this
>> morning) segfaults with PLplot. cmake-2.4.4 does not segfault with exactly
>> the same PLplot tree so I think the segfault problem must be due to
>> something wrong with cmake CVS HEAD, but that may be nothing to do with 
>> your
>> fix.  Is there a CVS tag I can use that will include your fix but still be
>> stable enough to work?  Or can you send me a patch of your fix to be
>> applied to 2.4.4?
> My guess is the crash has something to do with the fix, so I don't want to 
> put it on the branch.
> Can you run it in gdb and give me a call stack?

I rebuilt the cvs (checked out much earlier today) version of cmake with
-DCMAKE_BUILD_TYPE=Debug, and used valgrind (which always seems to give
better results than gdb with segfaults).

Here is the tail end of the valgrind/cmake output (with nothing from
valgrind before this except for boiler plate):

-- Configuring done
==11477== Invalid read of size 1
==11477==    at 0x1B9057F8: strlen (mac_replace_strmem.c:189)
==11477==    by 0x1B9A56B1: std::string::operator=(char const*) (in
/usr/lib/libstdc++.so.5.0.7)
==11477==    by 0x815676B: cmTarget::GetLocation(char const*)
(cmTarget.cxx:908)
==11477==    by 0x8153DCA: cmTarget::TraceVSDependencies(std::string,
cmMakefile*) (cmTarget.cxx:252)
==11477==    by 0x820BA97: cmLocalUnixMakefileGenerator3::Generate()
(cmLocalUnixMakefileGenerator3.cxx:100)
==11477==    by 0x81DEE2A: cmGlobalGenerator::Generate()
(cmGlobalGenerator.cxx:768)
==11477==    by 0x81E7CB6: cmGlobalUnixMakefileGenerator3::Generate()
(cmGlobalUnixMakefileGenerator3.cxx:124)
==11477==    by 0x8168345: cmake::Generate() (cmake.cxx:1810)
==11477==    by 0x816817B: cmake::Run(std::vector<std::string,
std::allocator<std::string> > const&, bool) (cmake.cxx:1790)
==11477==    by 0x810CE86: do_cmake(int, char**) (cmakemain.cxx:272)
==11477==    by 0x810C3DA: main (cmakemain.cxx:131)
==11477==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11477== 
==11477== Process terminating with default action of signal 11 (SIGSEGV)
==11477==  Access not within mapped region at address 0x0
==11477==    at 0x1B9057F8: strlen (mac_replace_strmem.c:189)
==11477==    by 0x1B9A56B1: std::string::operator=(char const*) (in
/usr/lib/libstdc++.so.5.0.7)
==11477==    by 0x815676B: cmTarget::GetLocation(char const*)
(cmTarget.cxx:908)
==11477==    by 0x8153DCA: cmTarget::TraceVSDependencies(std::string,
cmMakefile*) (cmTarget.cxx:252)
==11477==    by 0x820BA97: cmLocalUnixMakefileGenerator3::Generate()
(cmLocalUnixMakefileGenerator3.cxx:100)
==11477==    by 0x81DEE2A: cmGlobalGenerator::Generate()
(cmGlobalGenerator.cxx:768)
==11477==    by 0x81E7CB6: cmGlobalUnixMakefileGenerator3::Generate()
(cmGlobalUnixMakefileGenerator3.cxx:124)
==11477==    by 0x8168345: cmake::Generate() (cmake.cxx:1810)
==11477==    by 0x816817B: cmake::Run(std::vector<std::string,
std::allocator<std::string> > const&, bool) (cmake.cxx:1790)
==11477==    by 0x810CE86: do_cmake(int, char**) (cmakemain.cxx:272)
==11477==    by 0x810C3DA: main (cmakemain.cxx:131)
==11477== 
==11477== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 21 from 2)
==11477== malloc/free: in use at exit: 3000593 bytes in 7860 blocks.
==11477== malloc/free: 127385 allocs, 119525 frees, 188941770 bytes allocated.
==11477== For counts of detected errors, rerun with: -v
==11477== searching for pointers to 7860 not-freed blocks.
==11477== checked 3409720 bytes.
==11477== 
==11477== LEAK SUMMARY:
==11477==    definitely lost: 0 bytes in 0 blocks.
==11477==      possibly lost: 1321704 bytes in 226 blocks.
==11477==    still reachable: 1678889 bytes in 7634 blocks.
==11477==         suppressed: 0 bytes in 0 blocks.
==11477== Reachable blocks (those to which a pointer was found) are not shown.
==11477== To see them, rerun with: --show-reachable=yes
Segmentation fault

I hope this information is sufficient for you to find the segfault.

One other thing I noticed was pkg-config was not found by the cvs version of
cmake while 2.4.4 finds it.  This is because we include (the now obsolete)
UsePkgConfig.cmake which in turn includes FindPkgConfig.cmake.  But that new
module defines PKG_CONFIG_EXECUTABLE while UsePkgConfig.cmake used to define
PKGCONFIG_EXECUTABLE (which is what PLplot looks for).  I actually like the
new name better, but to preserve backwards compatibility for the obsolete
UsePkgConfig.cmake, I advise defining PKGCONFIG_EXECUTABLE there.  I know
you would like me to make yet another bug report at this point, but if you
don't mind this is so trivial to fix I hope that report won't be necessary.

Some of our platforms do not have pkg-config so our cmake configuration
logic is fairly well exercised in that case without any segfaults for
version 2.4.4.  So I doubt the different logical path taken by pkg-config
not being available is triggering the above segfault, but I thought I should
mention it.

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 Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________