View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0010717CMakeModulespublic2010-05-14 15:592016-06-10 14:31
ReporterDaniel Richard G. 
Assigned ToBill Hoffman 
PrioritynormalSeveritymajorReproducibilitysometimes
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010717: CheckIncludeFile.cmake sometimes finds files that aren't there
DescriptionI am using CMake 2.8.1 on an OSF/Tru64 system. My listfile uses CheckTypeSize.cmake to check for the availability of various C99 integer types, and this file in turn uses CheckIncludeFile.cmake to look for sys/types.h, stdint.h, and stddef.h.

On this system, the correct result of these checks is as follows:

-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - not found
-- Looking for stddef.h
-- Looking for stddef.h - found

Sometimes, however---maybe 1 out of every 2 or 3 tries, it's not hard to reproduce---I see this:

-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found

Which is bogus, of course; this system does not have stdint.h anywhere! So I used --debug-trycompile, and rigged CheckTypeSize.cmake to error out as soon as HAVE_STDINT_H was true, and poked around to see what might have been causing this erroneous result. Some telemetry:

cport@drum:/tmp/tgpack-test/CMakeFiles/CMakeTmp> gnu-stat CheckIncludeFile.c CMakeFiles/cmTryCompileExec.dir/CheckIncludeFile.c.o
  File: `CheckIncludeFile.c'
  Size: 113 Blocks: 2 IO Block: 8192 regular file
Device: 800406h/8389638d Inode: 146087 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 14/ cport) Gid: ( 15/ users)
Access: 2010-05-13 19:51:41.531453000 -0400
Modify: 2010-05-13 19:51:41.549021000 -0400
Change: 2010-05-13 19:51:41.549997000 -0400
  File: `CMakeFiles/cmTryCompileExec.dir/CheckIncludeFile.c.o'
  Size: 6856 Blocks: 14 IO Block: 8192 regular file
Device: 800406h/8389638d Inode: 152298 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 14/ cport) Gid: ( 15/ users)
Access: 2010-05-13 19:52:01.967532000 -0400
Modify: 2010-05-13 19:51:41.239629000 -0400
Change: 2010-05-13 19:51:41.239629000 -0400
cport@drum:/tmp/tgpack-test/CMakeFiles/CMakeTmp> cat CheckIncludeFile.c
#include <stdint.h>

#ifdef __CLASSIC_C__
int main()
{
  return 0;
}
#else
int main(void)
{
  return 0;
}
#endif
cport@drum:/tmp/tgpack-test/CMakeFiles/CMakeTmp> gnu-grep physadr_t CMakeFiles/cmTryCompileExec.dir/CheckIncludeFile.c.o
Binary file CMakeFiles/cmTryCompileExec.dir/CheckIncludeFile.c.o matches
cport@drum:/tmp/tgpack-test/CMakeFiles/CMakeTmp> gnu-grep -Rl physadr_t /usr/include
/usr/include/sys/types.h

Notice that the CheckIncludeFile.c.o object file slightly predates CheckIncludeFile.c, and the object file contains a type definition that appears only in sys/types.h. The object file thus appears to be from the sys/types.h check. And yet, the CMake run ended right after the stdint.h check was successful.

So it seems that the stdint.h check succeeded only because it didn't actually attempt to compile the test program #including the header, because for whatever reason, a dependency mechanism failed, and it re-used the compiled object from the successful sys/types.h check.

(The failing dependency mechanism does not appear to be the makefile processor, because neither setting MAKE=gmake or PATH-redirecting "make" to gmake makes the problem go away.)

I believe a fix would be for try_compile() to delete any existing output object file before it attempts compilation. Why take the risk?
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0024811)
David Cole (manager)
2011-01-17 16:02

 --debug-trycompile is only intended to be used for a single try_compile operation.

Using it for more than one try_compile operation will (and always has) produced spurious, probably inaccurate results.

Do not use it that way.

Isolate the single try_compile that is giving you problems and then use "--debug-trycompile"
(0024838)
Daniel Richard G. (reporter)
2011-01-17 17:47

 I think you're overlooking a couple of details:

1. The spurious results were initially obtained sans --debug-trycompile; I began to use that switch to investigate the problem;

2. --debug-trycompile, as far as is documented, only prevents the try-compile directory from being deleted (to allow debugging) and otherwise does not change the results or semantics of the compile attempts;

3. Isolating the try_compile() that is giving trouble won't help, because the problem appears to be caused by the immediately preceding instance of try_compile(). This is not a simple bug.
(0041698)
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-14 15:59 Daniel Richard G. New Issue
2010-08-03 12:23 Kovarththanan Rajaratnam Category CMake => Modules
2011-01-17 16:00 David Cole Assigned To => David Cole
2011-01-17 16:00 David Cole Status new => assigned
2011-01-17 16:02 David Cole Note Added: 0024811
2011-01-17 16:02 David Cole Status assigned => resolved
2011-01-17 16:02 David Cole Fixed in Version => CMake 2.8.4
2011-01-17 16:02 David Cole Resolution open => no change required
2011-01-17 17:47 Daniel Richard G. Note Added: 0024838
2011-01-17 17:47 Daniel Richard G. Status resolved => feedback
2011-01-17 17:47 Daniel Richard G. Resolution no change required => reopened
2011-01-17 17:50 David Cole Assigned To David Cole => Bill Hoffman
2011-01-17 17:50 David Cole Status feedback => assigned
2016-06-10 14:28 Kitware Robot Note Added: 0041698
2016-06-10 14:28 Kitware Robot Status assigned => resolved
2016-06-10 14:28 Kitware Robot Fixed in Version CMake 2.8.4 =>
2016-06-10 14:28 Kitware Robot Resolution reopened => moved
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team