MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0014226CMakeCMakepublic2013-06-17 15:012013-11-04 09:33
Reportersobukus 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformGNU/Linux x86-64 gccOSSource Mage GNU/LinuxOS Version
Product VersionCMake 2.8.11.1 
Target VersionFixed in Version 
Summary0014226: Fails to build, verison 2.8.10.2 was fine.
DescriptionThis is a 64 bit only box with a source-based GNU/Linux distro. The build of CMake itself fails with version 2.8.11.1, while the build with 2.8.10.2 works.

There is some confusion about 32 or 64 bit, apparently. The crucial bit from the attached logs:

[ 31%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o
In file included from /usr/src/cmake-2.8.11.1/Source/cm_sha2.h:42:0,
                 from /usr/src/cmake-2.8.11.1/Source/cmCryptoHash.cxx:15:
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:829:1: error: conflicting declaration 'int (* cmIML_INT_intptr_t__VERIFY__)[4]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:829:1: error: 'cmIML_INT_intptr_t__VERIFY__' has a previous declaration as 'int (* cmIML_INT_intptr_t__VERIFY__)[8]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:832:1: error: conflicting declaration 'int (* cmIML_INT_uintptr_t__VERIFY__)[4]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:832:1: error: 'cmIML_INT_uintptr_t__VERIFY__' has a previous declaration as 'int (* cmIML_INT_uintptr_t__VERIFY__)[8]'
make[2]: *** [Source/CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o] Error 1
make[2]: *** Waiting for unfinished jobs....
Steps To ReproduceThat's the tricky part: This seems to happen on my box only so far. Others with the same distro reported successful builds. It can be my specific set of tools in the chain, as the distro allows a rather free mix of versions.

But really, with the current setup, the old CMake builds fine, while the new one fails. So at least I can reproduce it reliably.
Additional Information
TagsNo tags attached.
Relationships
Attached Filesbz2 cmake-2.8.11.1.bz2 (4,703) 2013-06-17 15:01
https://public.kitware.com/Bug/file/4795/cmake-2.8.11.1.bz2
bz2 cmake-2.8.10.2.bz2 (16,824) 2013-06-17 15:01
https://public.kitware.com/Bug/file/4796/cmake-2.8.10.2.bz2
bz2 cmCryptoHash.cxx.bz2 (119,355) 2013-06-21 12:20
https://public.kitware.com/Bug/file/4800/cmCryptoHash.cxx.bz2
Issue History
Date ModifiedUsernameFieldChange
2013-06-17 15:01sobukusNew Issue
2013-06-17 15:01sobukusFile Added: cmake-2.8.11.1.bz2
2013-06-17 15:01sobukusFile Added: cmake-2.8.10.2.bz2
2013-06-19 10:14Brad KingNote Added: 0033327
2013-06-19 19:23sobukusNote Added: 0033338
2013-06-20 08:35Brad KingNote Added: 0033340
2013-06-20 08:36Brad KingNote Edited: 0033340bug_revision_view_page.php?bugnote_id=33340#r1199
2013-06-20 08:40Brad KingNote Added: 0033341
2013-06-20 08:59sobukusNote Added: 0033345
2013-06-20 09:05Brad KingNote Added: 0033346
2013-06-20 09:09sobukusNote Added: 0033349
2013-06-20 09:21Brad KingNote Added: 0033351
2013-06-20 09:34sobukusNote Added: 0033353
2013-06-20 09:41Brad KingNote Added: 0033354
2013-06-21 12:20sobukusFile Added: cmCryptoHash.cxx.bz2
2013-06-21 12:20sobukusNote Added: 0033367
2013-06-21 14:50Brad KingNote Added: 0033368
2013-06-22 07:33sobukusNote Added: 0033371
2013-06-24 08:26Brad KingNote Added: 0033373
2013-06-24 11:56sobukusNote Added: 0033375
2013-06-25 08:50Brad KingNote Added: 0033376
2013-06-25 10:02sobukusNote Added: 0033378
2013-06-25 10:08sobukusNote Added: 0033379
2013-06-25 10:17Brad KingNote Added: 0033380
2013-06-25 10:18Brad KingNote Added: 0033381
2013-06-25 10:18Brad KingStatusnew => resolved
2013-06-25 10:18Brad KingResolutionopen => no change required
2013-11-04 09:33Robert MaynardNote Added: 0034380
2013-11-04 09:33Robert MaynardStatusresolved => closed

Notes
(0033327)
Brad King   
2013-06-19 10:14   
The code reporting the error is configured from files in Utilities/KWIML in the source tree. They have no dependencies on outside files. The only difference between 2.8.10.2 and 2.8.11.1 in these files is in Utilities/KWIML/ABI.h.in. Try copying that file from 2.8.10.2 into your 2.8.11.1 source tree to see if the problem still occurs. If so that will rule out any change to that directory as the culprit.
(0033338)
sobukus   
2013-06-19 19:23   
Yes, the build works when replacing ABI.h.in with the version from 2.8.10.2 .
(0033340)
Brad King   
2013-06-20 08:35   
(edited on: 2013-06-20 08:36)
Okay, let's figure out which change within the differences is the problem. Please try with ABI.h.in from 2.8.11.1 plus this patch:

diff --git a/Utilities/KWIML/ABI.h.in b/Utilities/KWIML/ABI.h.in
index b71cdfb..7f4772a 100644
--- a/Utilities/KWIML/ABI.h.in
+++ b/Utilities/KWIML/ABI.h.in
@@ -253,9 +253,7 @@ suppression macro @KWIML@_ABI_NO_VERIFY was defined.
 #  else
 #   define @KWIML@_ABI_SIZEOF_LONG_LONG 0
 #  endif
-# elif defined(__GNUC__) /* GNU */
-#  define @KWIML@_ABI_SIZEOF_LONG_LONG 8
-# elif defined(__hpux) /* Old HP: no __HP_cc/__HP_aCC/__GNUC__ above */
+# elif defined(__hpux) && !defined(__GNUC__) /* Old HP: no __HP_cc/__HP_aCC above */
 #  define @KWIML@_ABI_SIZEOF_LONG_LONG 8
 # endif
 #endif


(0033341)
Brad King   
2013-06-20 08:40   
Discussion that led to the hunk reverted by the patch in 0014226:0033340 is here:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5788/focus=5794 [^]

along with a link to the commit making the change.
(0033345)
sobukus   
2013-06-20 08:59   
Works nicely.

Well, I didn't try the resulting build on anything, it just went through.
(0033346)
Brad King   
2013-06-20 09:05   
Interesting. The preprocessor logic in question begins here:

 http://cmake.org/gitweb?p=cmake.git;a=blob;f=Utilities/KWIML/ABI.h.in;hb=v2.8.11.1#l210 [^]

In order to get to the point the patch just identified changed we need a GNU compiler that does not define __SIZEOF_LONG_LONG__ or _LONGLONG.

What version of GCC is this?
(0033349)
sobukus   
2013-06-20 09:09   
14:59|dunkelstern:src# nano -w long.c
15:09|dunkelstern:src# gcc long.c
15:09|dunkelstern:src# ./a.out
8
15:10|dunkelstern:src# gcc --version
gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

15:10|dunkelstern:src# cat long.c
#include <stdio.h>

int main()
{
    printf("%i\n", __SIZEOF_LONG_LONG__);
    return 0;
}
(0033351)
Brad King   
2013-06-20 09:21   
Re 0014226:0033349: That's what is expected, but it explains why the code should work, not why it fails. Strange. Just for sanity, what about the c++ compiler? The build is failing in Source/cmCryptoHash.cxx which is a C++ source.
(0033353)
sobukus   
2013-06-20 09:34   
15:33|dunkelstern:src# g++ long.c
15:33|dunkelstern:src# ./a.out
8 0x7fffffffffffffff
15:33|dunkelstern:src# cat long.c
#include <stdio.h>

int main()
{
    printf("%i 0x%016llx\n", __SIZEOF_LONG_LONG__, __LONG_LONG_MAX__);
    return 0;
}


I still have to figure out what's special with my setup here. The flags shouldn't be it:

15:34|dunkelstern:src# g++ -march=core2 -fPIC -DPIC -pipe -O2 -g long.c
15:35|dunkelstern:src# ./a.out
8 0x7fffffffffffffff
(0033354)
Brad King   
2013-06-20 09:41   
Re 0014226:0033353: Try a ".cxx" extension to more closely match the failure case.

Also try "make VERBOSE=1" to see the full compilation command line that fails. Then run that but replace "-o xxx.o" with "-E -dD" and redirect the output to a file. That will show the full preprocessing output along with macros as they are defined.
(0033367)
sobukus   
2013-06-21 12:20   
See the new upload for the preprocessed source.
(0033368)
Brad King   
2013-06-21 14:50   
According to your preprocessed output:

# 213 "/usr/src/cmake-2.8.11.1/Utilities/cmIML/ABI.h"
#define cmIML_ABI_SIZEOF_LONG_LONG __SIZEOF_LONG_LONG__
# 275 "/usr/src/cmake-2.8.11.1/Utilities/cmIML/ABI.h"


we pick the right size for long long and no definitions result from the line the patch in question changes. However, I do see these lines in the output:

#define __SIZEOF_POINTER__ 8
...
# 129 "/usr/include/include/stdint.h"
typedef unsigned int uintptr_t;


Those all come from the compiler, and it is inconsistent.
(0033371)
sobukus   
2013-06-22 07:33   
Oh, dear. That's not from the compiler.

# 129 "/usr/include/include/stdint.h"

For some reason, I had a second include tree under /usr/include. Must be some strange remnant from testing build scripts. After removing that old tree (from around 2009), current cmake builds fine. I won't investigate how exactly those includes managed to define uintptr_t as unsigned int, as this install has always been 64 bit. I guess, with an incomplete second include tree being used, you can explain many weird things.

So, now I know what was different on my box. The question I still have: Why were those includes in /usr/include/include picked up by cmake? I don't see a reason why they should. /usr/include/include is not a system header path. Is cmake being smart by trying #include <include/header.h>?
(0033373)
Brad King   
2013-06-24 08:26   
Re 0014226:0033371: According to the preprocessed output the first appearance of that directory is here:

# 32 "/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../include/c++/4.6.3/x86_64-pc-linux-gnu/bits/os_defines.h" 3
...
#define __NO_CTYPE 1
# 1 "/usr/include/include/features.h" 1 3

Since os_defines.h does just "#include <features.h>" the /usr/include/include must be in the -I path, either explicitly on the command line or implicitly in the compiler configuration. You'll have to check the command line with "make VERBOSE=1".
(0033375)
sobukus   
2013-06-24 11:56   
This is the line I used for generating the preprocessed source:

cd /usr/src/cmake-2.8.11.1/Source && /usr/bin/g++ -DCMAKE_BUILD_WITH_CMAKE -march=core2 -fPIC -DPIC -pipe -O2 -g -I/usr/src/cmake-2.8.11.1/Utilities -I/usr/src/cmake-2.8.11.1/Source -I/usr/include/include -I/usr/src/cmake-2.8.11.1/Utilities/cmcompress -I/usr/src/cmake-2.8.11.1/Source/CTest -I/usr/src/cmake-2.8.11.1/Source/CursesDialog/form -E -dD -c /usr/src/cmake-2.8.11.1/Source/cmCryptoHash.cxx

Indeed, there it is. -I/usr/include/include. In contrast, running make VERBOSE=1 with 2.8.10.2 shows this:

 cd /usr/src/cmake-2.8.10.2/Source && /usr/bin/g++ -DCMAKE_BUILD_WITH_CMAKE -DCURL_STATICLIB -DLIBARCHIVE_STATIC -march=core2 -fPIC -DPIC -pipe -O2 -g -I/usr/src/cmake-2.8.10.2/Utilities -I/usr/src/cmake-2.8.10.2/Source -I/usr/src/cmake-2.8.10.2/Utilities/cmcompress -I/usr/src/cmake-2.8.10.2/Source/CTest -I/usr/src/cmake-2.8.10.2/Source/CursesDialog/form -o CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o -c /usr/src/cmake-2.8.10.2/Source/cmCryptoHash.cxx

Starting a build of 2.8.11.1 again, I don't see /usr/include/include ... removing the installed version ... nothing ... installing an older version (2.8.8; initially I had 2.8.4) ... hah, there it is again! Removing installed cmake again ... and the build still breaks.

Is there some funky caching going on? I don't seem to get very consistent results. Anyhow: Can you imagine where -I/usr/include/include enters the build? At least that should be settled for the next guy with stray header copies flying around.
(0033376)
Brad King   
2013-06-25 08:50   
Re 0014226:0033375: There shouldn't be any caching if you use a fresh build tree every time. Within a build tree look at CMakeCache.txt for where CMake stores paths to things it found. Is there a /usr/include/include in there?
(0033378)
sobukus   
2013-06-25 10:02   
It finds the zlib header in /usr/include/include and prefers it over the one in /usr/include. So Modules/FindZLIB.cmake adds this. Is find_path() supposed to add the path suffix twice? Sorry for my ignorance, I don't work with cmake myself. The docs don't tell me if it is supposed to search recursively
(0033379)
sobukus   
2013-06-25 10:08   
... old CMake uses an internal zlib ...
(0033380)
Brad King   
2013-06-25 10:17   
Re 0014226:0033378: In FindZLIB the find_path call that finds the header has the "PATH_SUFFIXES include" option which tells it to look at "include/" under any other path it is told to search. One of the places it is told to search is /usr/include so that is why it finds this.
(0033381)
Brad King   
2013-06-25 10:18   
Resolving as "no change required" because the cause of the failure is due to the extraneous files on a single machine.
(0034380)
Robert Maynard   
2013-11-04 09:33   
Closing resolved issues that have not been updated in more than 4 months.