|
Notes |
|
|
(0028955)
|
|
Brad King
|
|
2012-03-23 08:46
|
|
|
Something must be going wrong with detection and configuration of the type sizes. Please attach the configured FundamentalType.h, CMakeCache.txt, and CMakeFiles/CMake*.log from the build tree. |
|
|
|
(0028956)
|
|
Flávio J. Saraiva
|
|
2012-03-23 09:51
|
|
To reproduce the problematic environment I uninstalled all gcc4 packages and then installed gcc4-core. Then on a fresh cmake-2.8.7 did:
$ ./bootstrap
(...snip...)
$ make
(...snip...)
$ gcc --version
gcc (GCC) 4.5.3
Copyright (C) 2010 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.
$ g++ --version
g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 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. |
|
|
|
(0028957)
|
|
Brad King
|
|
2012-03-23 09:55
|
|
Okay, so the type size checks are run with the C compiler and end up configuring this in FundamentalType.h:
/* The size of fundamental types. Types that do not exist have size 0. */
#define cmsys_SIZEOF_CHAR 1
#define cmsys_SIZEOF_SHORT __SIZEOF_SHORT__
#define cmsys_SIZEOF_INT __SIZEOF_INT__
#define cmsys_SIZEOF_LONG __SIZEOF_LONG__
#define cmsys_SIZEOF_LONG_LONG __SIZEOF_LONG_LONG__
#define cmsys_SIZEOF___INT64 0
Then when this is included by the older C++ compiler it does not define the __SIZEOF_*__ macros so they all evaluate to "0" in the later preprocessor tests. |
|
|
|
(0028958)
|
|
Brad King
|
|
2012-03-23 09:59
|
|
> I suggest adding a test to check if C and CXX compilers are compatible
How might one detect that? The overlap between C and C++ is huge and any tiny detail might mismatch. The incompatibility in this particular case is quite obscure. |
|
|
|
(0028959)
|
|
Flávio J. Saraiva
|
|
2012-03-23 11:24
|
|
They agree on the size but not the macros... that can happen when the C and CXX compilers don't have the same version or when they have different brands.
In this case incompatibility means a mismatch of macros, so testing for incompatibility means testing if both compilers have the macro before using it.
It's probably safe to assume that they are compatible if their brands and versions match. Using different versions or brands is very rare, but still possible. =~~ |
|
|
|
(0028960)
|
|
Flávio J. Saraiva
|
|
2012-03-23 12:53
|
|
At the very least I expect a warning... I probably wouldn't notice the cause if I didn't start doing Nightly builds for the dashboard. =~~
I'll keep doing Nightly builds with the problematic environment and attach those files as notes. (site=flaviojs.laptop ; build=Cygwin) |
|
|
|
(0029070)
|
|
Flávio J. Saraiva
|
|
2012-04-03 22:32
|
|
|
|
|
(0029393)
|
|
Brad King
|
|
2012-05-03 07:24
|
|
This commit:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=221b5b69 [^]
removes dependencies on the FundamentalType header causing the reported issue.
Now your dashboard reports that things build all the way until the link step, at which point it fails with:
undefined reference to `___gxx_personality_sj0'
undefined reference to `__Unwind_SjLj_Register'
undefined reference to `__Unwind_SjLj_Resume'
undefined reference to `__Unwind_SjLj_Unregister'
This comes from incompatible exception handling ABIs used by the (vastly) different versions of gcc and g++. The compilers are in compatible so there is no point in testing the combination.
As I said in 0013059:0028958 it is impossible to detect full compatibility between compilers up front. |
|
|
|
(0031118)
|
|
David Cole
|
|
2012-10-01 13:22
|
|
|
Closing resolved issues that have not been updated in more than 4 months. |
|
CMakeCache.txt (91,521) 2012-03-23 09:49
FundamentalType.h (5,436) 2012-03-23 09:50