Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/7/2012 6:12 AM, Rolf Eike Beer wrote:
This has changed. It fails now for vs11-x64 on amber10 and for Linux64-
bullseye-cov on hythloth. amber10 seems to have an unrelated, general problem.
What's wrong with the bullseye I have no idea, but this goes wrong for the C++
test and some others, too.
Ignore amber10. The machine has some corruption on it. We've been working
to move those builds to some clean machines or VMs.
I wonder if the BullsEye coverage tool ends up leaving errno set to non-zero
after program startup. By returning it directly the return code from the test
executable ends up as non-zero so CTest thinks it failed. This works around
the problem:
diff --git a/Tests/Module/CheckSymbolExists/errno.c
b/Tests/Module/CheckSymbolExists/errno.c
index 6010f7c..da78f02 100644
--- a/Tests/Module/CheckSymbolExists/errno.c
+++ b/Tests/Module/CheckSymbolExists/errno.c
@@ -2,5 +2,6 @@
int main()
{
+ errno = 0;
return errno;
}
However the CheckCXXSymbolExist test fails:
For the bullseye (see above) and because the dummy executable fails for
Borland C++. return errno; doesn't work in C++ mode, I have no idea what's
that for a screwup. And especially why searching for that symbol using
CheckCXXSymbolExists works but using it doesn't.
When you use cerrno shouldn't you reference std::errno and not errno?
However, even that doesn't work because Borland's treatment of errno in
cerrno ends up preprocessing to
namespace std { extern C { extern int * __cdecl __errno(void); } }
int main() { return (*__errno()); }
and __errno() is not visible outside std::. Adding std:: would end up
giving return std::(*__errno()) which of course doesn't work. What works
is return (*std::__errno()) but they do not define the macro that way ;)
Using just errno.h works for Borland.
-Brad
diff --git a/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
b/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
index c55c05d..0e57bab 100644
--- a/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
+++ b/Tests/Module/CheckCXXSymbolExists/CMakeLists.txt
@@ -31,9 +31,10 @@ endforeach()
set(CMAKE_TRY_COMPILE_CONFIGURATION ${CMAKE_BUILD_TYPE})
unset(CSE_RESULT_ERRNO_CERRNO CACHE)
-MESSAGE(STATUS Checking cerrno)
-
-check_cxx_symbol_exists(errno cerrno CSE_RESULT_ERRNO_CERRNO)
+if(NOT BORLAND)
+ MESSAGE(STATUS Checking cerrno)
+ check_cxx_symbol_exists(errno cerrno CSE_RESULT_ERRNO_CERRNO)
+endif()
IF (NOT CSE_RESULT_ERRNO_CERRNO)
unset(CSE_RESULT_ERRNO_ERRNOH CACHE)
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/9/2012 9:19 AM, Rolf Eike Beer wrote: What about just putting using std; before the main? Does that help? I assume you mean using namespace std; Yes, it works. That will also take care of the normal cerrno case. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/5/2012 8:25 AM, Brad King wrote: So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. Sounds good. The new CheckSymbolExists test works everywhere! http://www.cdash.org/CDash/testSummary.php?project=1name=CheckSymbolExistsdate=2012-01-06 However the CheckCXXSymbolExist test fails: http://www.cdash.org/CDash/testSummary.php?project=1name=CheckCXXSymbolExistsdate=2012-01-06 I think it is because of a leftover --debug-trycompile option in the test line. That option works only when a single try-compile is invoked. Also, the tests are currently added differently from the other tests and are not handled by our make test_clean target. Furthermore the tests only get cleaned up by the file(REMOVE...) code in their CMakeLists.txt files when the main CMake build tree re-configures. Please change the way the tests are added to be consistent with the Module.CheckTypeSize test. IOW most of what is currently CMakeLists.txt.in can just go in CMakeLists.txt and the directory should not have its own add_test call. If you want to ensure that the try-compiles always re-run then add a line like unset(CSE_RESULT_... CACHE) just before each call to a check macro. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
Brad King wrote: On 1/5/2012 8:25 AM, Brad King wrote: So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. Sounds good. However the CheckCXXSymbolExist test fails: http://www.cdash.org/CDash/testSummary.php?project=1name=CheckCXXSymbolExi stsdate=2012-01-06 I think it is because of a leftover --debug-trycompile option in the test line. That option works only when a single try-compile is invoked. I've removed this. There is also a second problem: some builds (like bcc55) failed only because they could not find errno in errno.h. I've changed the C++ test to check in cerrno first, which seems to have fixed at least the bcc55 continuous build. Also, the tests are currently added differently from the other tests and are not handled by our make test_clean target. Furthermore the tests only get cleaned up by the file(REMOVE...) code in their CMakeLists.txt files when the main CMake build tree re-configures. Please change the way the tests are added to be consistent with the Module.CheckTypeSize test. IOW most of what is currently CMakeLists.txt.in can just go in CMakeLists.txt and the directory should not have its own add_test call. The difference is that my test only does configuration and does not build an executable, so the --build-and-test stuff will not work. If you want to ensure that the try-compiles always re-run then add a line like unset(CSE_RESULT_... CACHE) just before each call to a check macro. Done. I see that there are submit errors like this: (SendEmail): User: Rolf Eike Beer is not registered (or has no email) for the project 1 Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/6/2012 1:55 PM, Rolf Eike Beer wrote: The difference is that my test only does configuration and does not build an executable, so the --build-and-test stuff will not work. Lots of tests are like that. They just create a tiny dummy executable to build and link. That's why I pointed at CheckTypeSize as an example. I see that there are submit errors like this: (SendEmail): User: Rolf Eike Beer is not registered (or has no email) for the project 1 You need to register an account on CDash and set your author info. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. The subject of this thing is to provoke a compile error if the prototype doesn't match. And it even introduced the symbol _itself_, so it could even fail if you would provide the correct libraries the symbol is in using CMAKE_REQUIRED_LIBRARIES. So for me it looks like it could have the optimization problem, but that wouldn't be a problem here as the symbol itself is not what we are interested in at that point. But it's usage of CMAKE_REQUIRED_LIBRARIES is completely wrong in my eyes as it could make the test actually fail when it should be successful. It shouldn't use any libraries at all IMHO. And even then it could go wrong when you reintroduce a symbol from the standard libraries, which could cause an error in the linker because of duplicate symbols. Or one would have to drop the newly introduced symbol in this file at all, using _only_ the symbol from the provided libraries. And then we would have the optimization problem, but if that is solved the whole thing can be made reliable at all. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. This one needs rework, too, but that should go into a separate topic. Opinions? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/5/2012 4:47 AM, Rolf Eike Beer wrote: Brad King wrote: Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it has the same problem. I have looked into this and I don't think it has. Okay. As you said the concerns with that one are another topic. So I will go and fix some small typos I've found in the existing tests, repush and merge to next, so we see if Check*SymbolExists will work. Sounds good. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Pushed updated branch. Please review and merge to next if you like it.
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
Will look at.
There are a few problems with the current test. The configured
cse.cmake scripts end up driving the test builds using the CMake that
was used to configure CMake's build tree, not the one that was just built
and should be tested.
Also they don't select the generator properly so will only work on Unix-
like systems.
I don't think you need to create a whole new build tree for every test.
You can do all the test try-compiles right in the main test CMakeLists.txt
file, just with different result cache variable names
foreach(_config_type Release RelWithDebInfo MinSizeRel Debug)
set(CMAKE_TRY_COMPILE_CONFIGURATION ${_config_type})
check_symbol_exists(...)
endforeach()
In order to test things like -O3, just add them temporarily to the
CMAKE_C_FLAGS or CMAKE_CXX_FLAGS variables.
Nice. Will clean this up. When I put this directly into the CMakeLists.txt
the other problems should vanish, no?
Finally, I'd like to tweak the first commit message slightly:
CheckSymbolExists: try to force the compiler to keep the referenced
symbol
s/try to//
previous version was not really using this. This lead to symbols that
are
s/lead to/leads to/
No problem.
Eike
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/4/2012 9:50 AM, Rolf Eike Beer wrote: Nice. Will clean this up. When I put this directly into the CMakeLists.txt the other problems should vanish, no? Yes, I think so. That is one reason I suggested the approach. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
Am Mittwoch, 4. Januar 2012, 10:02:32 schrieb Brad King: On 1/4/2012 9:50 AM, Rolf Eike Beer wrote: Nice. Will clean this up. When I put this directly into the CMakeLists.txt the other problems should vanish, no? Yes, I think so. That is one reason I suggested the approach. Ok, I've updated the branch. The CheckPrototypeDefinition part is still missing, I'll see when I find time for it. Greetings, Eike signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On 1/2/2012 5:24 PM, Rolf Eike Beer wrote:
It looks like gcc simply optimizes out any reference to the tested symbol.
Given the fact that we don't really ever use that symbol anywhere it is even
correct to do so. Just that this is not what we want.
Yuck. Clearly a less-optimizable approach is needed.
I pushed a topic test-symbol-exists to stage that verifies that this is indeed
a problem in Check{,CXX}SymbolExists, it iterates through all build
configurations (were this problem does _not_ happen) and later explicitely
adds a -O3 test if it is gcc/g++ which then _does_ fail.
So, there are 3 points that I need advise:
-what should happen with this topic? Should I merge it to next? Then we will
get a ton of failures on at least everything that is using GNU compilers.
Certainly we should add tests for these modules. They are critical to
many projects. However, let's not add a test when we know it will break
immediately. Please also rebase the topic so it does not depend on your
FindDoxygen topic. Add a commit prior to the test to fix the behavior
as discussed below.
-which other compilers can be tested this way, I mean using -O3? From what I
know Clang does understand this and even -O4, what is about the Intel one?
Let's start with the GNU case and add more later. I suspect that if we can
convince GCC -O3 to keep the symbol (see below) then no other compiler will
be able to optimize it out.
-how to fix this thing at the end? I was thinking about just doing
#includestdio.h
printf(%s is at %p\n, ${SYMBOL},${SYMBOL}));
Is anyone aware of some place where this wouldn't work? Or should I just put
this in and try out?
We don't want the test to depend on any symbols other than the one tested,
even runtime library symbols. Some cross-compilers may not provide everything
by default. We just need to make the return value depend on the symbol. I
worked this out in Modules/CMakeCCompilerId.c.in. Note that the return
value should also depend on a runtime argument (argc) so the optimizer cannot
make any assumptions.
I think this will work:
int main(int argc, char* argv[])
{
(void)argv;
return ((int*)(SYMBOL))[argc];
}
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CheckSymbolExists is unreliable
On Tue, Jan 3, 2012 at 2:17 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Sorry, that was not intentional. I dropped the previous branch and created a
new one, based on current master. It has 2 commits: the first one introducing
the (hopefully) fixed CheckSymbolExists.cmake, the second one adding the
tests. It also adds a positive test: it checks if errno can be found in
errno.h for both C and C++. Hope this will not break on some strange machines.
Nice, thanks.
int main(int argc, char* argv[])
{
(void)argv;
return ((int*)(SYMBOL))[argc];
}
It looks like, at least it survives my -O3 test.
Great.
Pushed updated branch. Please review and merge to next if you like it.
Can you handle Modules/CheckPrototypeDefinition.cmake too? I think it
has the same problem.
There are a few problems with the current test. The configured cse.cmake
scripts end up driving the test builds using the CMake that was used to
configure CMake's build tree, not the one that was just built and should
be tested. Also they don't select the generator properly so will only work
on Unix-like systems.
I don't think you need to create a whole new build tree for every test.
You can do all the test try-compiles right in the main test CMakeLists.txt
file, just with different result cache variable names
foreach(_config_type Release RelWithDebInfo MinSizeRel Debug)
set(CMAKE_TRY_COMPILE_CONFIGURATION ${_config_type})
check_symbol_exists(...)
endforeach()
In order to test things like -O3, just add them temporarily to the
CMAKE_C_FLAGS or CMAKE_CXX_FLAGS variables.
Finally, I'd like to tweak the first commit message slightly:
CheckSymbolExists: try to force the compiler to keep the referenced symbol
s/try to//
previous version was not really using this. This lead to symbols that are
s/lead to/leads to/
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] CheckSymbolExists is unreliable
In case anyone has a deja-vu: yes, it's true. This problem came up when I
tried to fix bug 11333. Once a fix for that was out a user found out that his
pthreads library was no longer detected. The root cause for this is that the
CheckSymbolExists and CheckCXXSymbolExists macros do not work if you use
gcc/g++ and -O3.
It looks like gcc simply optimizes out any reference to the tested symbol.
Given the fact that we don't really ever use that symbol anywhere it is even
correct to do so. Just that this is not what we want.
I pushed a topic test-symbol-exists to stage that verifies that this is indeed
a problem in Check{,CXX}SymbolExists, it iterates through all build
configurations (were this problem does _not_ happen) and later explicitely
adds a -O3 test if it is gcc/g++ which then _does_ fail.
So, there are 3 points that I need advise:
-what should happen with this topic? Should I merge it to next? Then we will
get a ton of failures on at least everything that is using GNU compilers.
-which other compilers can be tested this way, I mean using -O3? From what I
know Clang does understand this and even -O4, what is about the Intel one?
-how to fix this thing at the end? I was thinking about just doing
#include stdio.h
printf(%s is at %p\n, ${SYMBOL}, ${SYMBOL}));
Is anyone aware of some place where this wouldn't work? Or should I just put
this in and try out?
Greetings,
Eike
signature.asc
Description: This is a digitally signed message part.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
