(0033327)
Brad King (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (reporter)
2013-06-20 08:59

Works nicely.

Well, I didn't try the resulting build on anything, it just went through.

(0033346)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
2013-06-21 12:20

See the new upload for the preprocessed source.

(0033368)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (reporter)
2013-06-25 10:08

... old CMake uses an internal zlib ...

(0033380)
Brad King (manager)
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 (manager)
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 (manager)
2013-11-04 09:33

Closing resolved issues that have not been updated in more than 4 months.

Notes
(0033327) Brad King (manager) 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 (reporter) 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 (manager) 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 (manager) 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 (reporter) 2013-06-20 08:59	Works nicely. Well, I didn't try the resulting build on anything, it just went through.

(0033346) Brad King (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 2013-06-21 12:20	See the new upload for the preprocessed source.

(0033368) Brad King (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (reporter) 2013-06-25 10:08	... old CMake uses an internal zlib ...

(0033380) Brad King (manager) 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 (manager) 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 (manager) 2013-11-04 09:33	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2013-06-17 15:01	sobukus	New Issue
2013-06-17 15:01	sobukus	File Added: cmake-2.8.11.1.bz2
2013-06-17 15:01	sobukus	File Added: cmake-2.8.10.2.bz2
2013-06-19 10:14	Brad King	Note Added: 0033327
2013-06-19 19:23	sobukus	Note Added: 0033338
2013-06-20 08:35	Brad King	Note Added: 0033340
2013-06-20 08:36	Brad King	Note Edited: 0033340
2013-06-20 08:40	Brad King	Note Added: 0033341
2013-06-20 08:59	sobukus	Note Added: 0033345
2013-06-20 09:05	Brad King	Note Added: 0033346
2013-06-20 09:09	sobukus	Note Added: 0033349
2013-06-20 09:21	Brad King	Note Added: 0033351
2013-06-20 09:34	sobukus	Note Added: 0033353
2013-06-20 09:41	Brad King	Note Added: 0033354
2013-06-21 12:20	sobukus	File Added: cmCryptoHash.cxx.bz2
2013-06-21 12:20	sobukus	Note Added: 0033367
2013-06-21 14:50	Brad King	Note Added: 0033368
2013-06-22 07:33	sobukus	Note Added: 0033371
2013-06-24 08:26	Brad King	Note Added: 0033373
2013-06-24 11:56	sobukus	Note Added: 0033375
2013-06-25 08:50	Brad King	Note Added: 0033376
2013-06-25 10:02	sobukus	Note Added: 0033378
2013-06-25 10:08	sobukus	Note Added: 0033379
2013-06-25 10:17	Brad King	Note Added: 0033380
2013-06-25 10:18	Brad King	Note Added: 0033381
2013-06-25 10:18	Brad King	Status	new => resolved
2013-06-25 10:18	Brad King	Resolution	open => no change required
2013-11-04 09:33	Robert Maynard	Note Added: 0034380
2013-11-04 09:33	Robert Maynard	Status	resolved => closed

Relationships