We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 2689 - the CMake build with GCC is far too lenient
Summary: the CMake build with GCC is far too lenient
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: build (show other bugs)
Version: 2.0.3
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-17 18:51 UTC by Benoit Pierre
Modified: 2014-08-17 20:50 UTC (History)
0 users

See Also:


Attachments
use -Wall and -Wshadow when building with CMake and GCC (721 bytes, patch)
2014-08-17 18:51 UTC, Benoit Pierre
Details | Diff
use -Wl,--no-undefined when building with CMake and GCC (666 bytes, patch)
2014-08-17 20:03 UTC, Benoit Pierre
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Benoit Pierre 2014-08-17 18:51:22 UTC
Created attachment 1828 [details]
use -Wall and -Wshadow when building with CMake and GCC

1. no warning compilation flags are used (-Wall, -Wshadow, ...)
2. the resulting shared library is linked without checking for missing symbols

So it's possible to add some code calling a mythical SDL_foobar function, and get a successful build, with zero warnings...

The attached patch add -Wall and -Werror to the GCC compilation flags when supported.
Comment 1 Benoit Pierre 2014-08-17 20:03:44 UTC
Created attachment 1829 [details]
use -Wl,--no-undefined when building with CMake and GCC

This patch adds -Wl,--no-undefined to the linker flags when building with CMake and GCC so unresolved symbols are detected when linking the shared library version of SDL.
Comment 2 Sam Lantinga 2014-08-17 20:16:54 UTC
These patches are in!
https://hg.libsdl.org/SDL/rev/39eb61ccbc82
https://hg.libsdl.org/SDL/rev/22232029f074

If you set CMAKE_REQUIRED_FLAGS, and the test fails, do you need to re-set CMAKE_REQUIRED_FLAGS to the previous value?
Comment 3 Benoit Pierre 2014-08-17 20:25:48 UTC
No, you're right, it should be reset with set(CMAKE_REQUIRED_FLAGS) so has not to impact latter tests with check_c_compiler_flag (thankfully there are currently none).
Comment 4 Sam Lantinga 2014-08-17 20:50:20 UTC
Okay, fixed!
https://hg.libsdl.org/SDL/rev/029f8d643dbe