MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0013208CMakeCMakepublic2012-05-10 09:242016-06-10 14:31
ReporterAntonio Ospite 
Assigned ToKitware Robot 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSDebian GNU/LinuxOS VersionWheezy
Product VersionCMake 2.8.8 
Target VersionFixed in Version 
Summary0013208: check_symbol_exists() fails when "-pedantic-errors" is added to CMAKE_C_FLAGS
DescriptionHi,

I just wanted to keep memory of that, the easy workaround is to add "-pedantic-errors" to more specific variables like CMAKE_C_FLAGS_DEBUG or CMAKE_C_FLAGS_RELEASE.

Thanks,
   Antonio Ospite
   http://ao2.it [^]
Steps To ReproduceTry with this minimal CMakeLists.txt:

cmake_minimum_required(VERSION 2.8)
include(CheckSymbolExists)

set(CMAKE_C_FLAGS "-pedantic-errors")
check_symbol_exists(fwrite stdio.h HAVE_FWRITE)

if (NOT HAVE_FWRITE)
  message(FATAL_ERROR "fwrite not available...")
endif()
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-05-10 09:24Antonio OspiteNew Issue
2012-05-10 10:06Antonio OspiteNote Added: 0029462
2012-05-16 15:00sobigboyNote Added: 0029484
2012-05-16 16:08Antonio OspiteNote Added: 0029486
2012-05-16 17:30sobigboyNote Edited: 0029484bug_revision_view_page.php?bugnote_id=29484#r654
2012-05-21 16:47Antonio OspiteNote Added: 0029536
2012-05-21 16:48Antonio OspiteNote Edited: 0029536bug_revision_view_page.php?bugnote_id=29536#r658
2012-05-21 16:52Antonio OspiteNote Added: 0029537
2012-08-11 21:35David ColeStatusnew => backlog
2012-08-11 21:35David ColeNote Added: 0030420
2013-06-04 01:14Christopher Sean MorrisonNote Added: 0033219
2016-06-10 14:28Kitware RobotNote Added: 0042045
2016-06-10 14:28Kitware RobotStatusbacklog => resolved
2016-06-10 14:28Kitware RobotResolutionopen => moved
2016-06-10 14:28Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0029462)
Antonio Ospite   
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   
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   
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   
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   
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   
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   
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   
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.