Notes
(0029462) Antonio Ospite (reporter) 2012-05-10 10:06	Ah if you look into CMakeFiles/CMakeError.log it is easy to see what the actual issue is: /tmp/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: In function ‘main’: /tmp/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:11: error: ISO C forbids conversion of function pointer to object pointer type [-pedantic]

(0029484) sobigboy (reporter) 2012-05-16 15:00 edited on: 2012-05-16 17:30	This issue may be related to ID 0013222. http://public.kitware.com/Bug/view.php?id=13222 [^]

(0029486) Antonio Ospite (reporter) 2012-05-16 16:08	yes sobigboy, I think the two issues can be generalized into "check_function_exists(), the check_library_exists(), and the find_package() fail if there is some troublesome option in CMAKE_C_FLAGS" as they seem to rely on compilation of a c program to provide their services. Maybe procedures internal to the cmake system should not rely on user settings like CMAKE_C_FLAGS? P.S. how about putting direct links when mentioning related issues? (editing your messages would be great for future readers)

(0029536) Antonio Ospite (reporter) 2012-05-21 16:47 edited on: 2012-05-21 16:48	Another example of how setting CMAKE_C_FLAGS can affect the behavior of internal cmake calls like check_symbol_exists(), if "-std=c99" is added to CMAKE_C_FLAGS then gcc (I don't know about other compilers), requires "Feature Test Macros" but these can't be simply specified with add_definitions(): ------------------------------------- cmake_minimum_required(VERSION 2.8) project(test C) include(CheckSymbolExists) # This does not work set(CMAKE_C_FLAGS "-std=c99") add_definitions("-D_POSIX_C_SOURCE=2") # needed for getopt to be available # This would work, but isn't it overkill? #set(CMAKE_C_FLAGS "-std=c99 -D_POSIX_C_SOURCE=2") check_symbol_exists(sigaction signal.h HAVE_SIGACTION) if (NOT HAVE_SIGACTION) message(FATAL_ERROR "sigaction not available...") endif() ---------------------------------------------------- What do cmake devs think about that? Thanks, Antonio

(0029537) Antonio Ospite (reporter) 2012-05-21 16:52	Ah, as a workaround, if I do this, the symbol can be found: set(CMAKE_REQUIRED_DEFINITIONS -D_POSIX_C_SOURCE=2) check_symbol_exists(sigaction signal.h HAVE_SIGACTION) set(CMAKE_REQUIRED_DEFINITIONS)

(0030420) David Cole (manager) 2012-08-11 21:35	Sending old, never assigned issues to the backlog. (The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...) If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^] It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.

(0033219) Christopher Sean Morrison (reporter) 2013-06-04 01:14	We just ran into this issue in a bad way with BRL-CAD. We need to test for symbols that are available but not declared for certain compilation modes (e.g., fileno() with gcc -std=gnu99 -pedantic). We need/want the test to use our CMAKE_C_FLAGS so that it picks up our compile mode and tests correctly. The current CHECK_SYMBOL_EXISTS does this, but the C test program it writes is nfg. Specifically, the line: return ((int*)(&fileno))[argc]; results in a "error: ISO C forbids conversion of function pointer to object pointer type" and worse, it's wrapped in a #ifndef on the symbol which will make the test fail if it's a preprocessor symbol. What we really want is to just no-op the symbol altogether (like is done in AC_CHECK_DECL): (void)symbol; This will report a failure if the header(s) don't declare symbol, regardless of whether it's a preprocessor-wrapped symbol, and will pass compilation if it was declared without warning. Basically, this commit broke it for us: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=813eca64160509465c0e557aa98c9b0f828e47a9 [^]

(0042045) Kitware Robot (administrator) 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.

Issue History
Date Modified	Username	Field	Change
2012-05-10 09:24	Antonio Ospite	New Issue
2012-05-10 10:06	Antonio Ospite	Note Added: 0029462
2012-05-16 15:00	sobigboy	Note Added: 0029484
2012-05-16 16:08	Antonio Ospite	Note Added: 0029486
2012-05-16 17:30	sobigboy	Note Edited: 0029484
2012-05-21 16:47	Antonio Ospite	Note Added: 0029536
2012-05-21 16:48	Antonio Ospite	Note Edited: 0029536
2012-05-21 16:52	Antonio Ospite	Note Added: 0029537
2012-08-11 21:35	David Cole	Status	new => backlog
2012-08-11 21:35	David Cole	Note Added: 0030420
2013-06-04 01:14	Christopher Sean Morrison	Note Added: 0033219
2016-06-10 14:28	Kitware Robot	Note Added: 0042045
2016-06-10 14:28	Kitware Robot	Status	backlog => resolved
2016-06-10 14:28	Kitware Robot	Resolution	open => moved
2016-06-10 14:28	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships