MantisBT - CMake
View Issue Details
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?
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-05-14 15:59Daniel Richard G.New Issue
2010-08-03 12:23Kovarththanan RajaratnamCategoryCMake => Modules
2011-01-17 16:00David ColeAssigned To => David Cole
2011-01-17 16:00David ColeStatusnew => assigned
2011-01-17 16:02David ColeNote Added: 0024811
2011-01-17 16:02David ColeStatusassigned => resolved
2011-01-17 16:02David ColeFixed in Version => CMake 2.8.4
2011-01-17 16:02David ColeResolutionopen => no change required
2011-01-17 17:47Daniel Richard G.Note Added: 0024838
2011-01-17 17:47Daniel Richard G.Statusresolved => feedback
2011-01-17 17:47Daniel Richard G.Resolutionno change required => reopened
2011-01-17 17:50David ColeAssigned ToDavid Cole => Bill Hoffman
2011-01-17 17:50David ColeStatusfeedback => assigned
2016-06-10 14:28Kitware RobotNote Added: 0041698
2016-06-10 14:28Kitware RobotStatusassigned => resolved
2016-06-10 14:28Kitware RobotFixed in VersionCMake 2.8.4 =>
2016-06-10 14:28Kitware RobotResolutionreopened => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0024811)
David Cole   
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.   
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   
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.