Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clang++: error: unsupported option '-fsanitize=leak' for target 'x86_64-apple-darwin23.6.0' #65

Open
ClausKlein opened this issue Nov 1, 2024 · 9 comments · May be fixed by #76
Open
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@ClausKlein
Copy link

bash-5.2$ cmake --workflow --preset gcc-debug  
Executing workflow step 1 of 3: configure preset "gcc-debug"

Preset CMake variables:

  CMAKE_BUILD_TYPE="Debug"
  CMAKE_CXX_COMPILER="g++"
  CMAKE_CXX_FLAGS="-fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined"
  CMAKE_CXX_STANDARD="17"

-- The CXX compiler identification is AppleClang 16.0.0.16000026
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ - broken
CMake Error at /usr/local/Cellar/cmake/3.30.5/share/cmake/Modules/CMakeTestCXXCompiler.cmake:73 (message):
  The C++ compiler

    "/usr/bin/g++"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: '/Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf'
    
    Run Build Command(s): /usr/local/bin/ninja -v cmTC_abf57
    [1/2] /usr/bin/g++   -fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined  -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.7 -MD -MT CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -c /Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf/testCXXCompiler.cxx
    FAILED: CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o 
    /usr/bin/g++   -fsanitize=address -fsanitize=pointer-compare -fsanitize=pointer-subtract -fsanitize=leak -fsanitize=undefined  -std=gnu++17 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.1.sdk -mmacosx-version-min=14.7 -MD -MT CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -MF CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o.d -o CMakeFiles/cmTC_abf57.dir/testCXXCompiler.cxx.o -c /Users/clausklein/Workspace/cpp/beman-project/exemplar/build/gcc-debug/CMakeFiles/CMakeScratch/TryCompile-h6rdZf/testCXXCompiler.cxx
    clang++: error: unsupported option '-fsanitize=leak' for target 'x86_64-apple-darwin23.6.0'
    ninja: build stopped: subcommand failed.
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:5 (project)


-- Configuring incomplete, errors occurred!
bash-5.2$ 
@bretbrownjr bretbrownjr added bug Something isn't working help wanted Extra attention is needed labels Nov 1, 2024
@ClausKlein
Copy link
Author

You may find some good inspiration for modern C++ with CMake using workflow presets here:
ClausKlein/cmake-init-modules#4

i.e ci.yml
and CMakeUserPresets.jsonnet

@camio
Copy link
Contributor

camio commented Nov 1, 2024

I was able to reproduce this on OSX with Apple silicon. The issue is that OSX has a g++ executable that isn't gcc, it's Apple clang.

(base) dsankel@Davids-Mac-Studio exemplar % /usr/bin/g++ --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Apple clang doesn't have a "leak" sanitizer like gcc does. One way to fix is to add clang-debug/clang-release presets and point people to those when they're on an OSX platform.

@ClausKlein
Copy link
Author

. One way to fix is to add clang-debug/clang-release presets and point people to those when they're on an OSX platform.

An other way is to use a Module like Sanitizers.cmake and keep the preset generic.

Same for compiler warnings: CompilerWarnings.cmake

This has also the advantage of not propagating the Sanitizer settings, coverage compile flags, or CompilerWarnings to the external projects used with FetchContents.

See for usage examples

@wusatosi
Copy link
Member

wusatosi commented Nov 8, 2024

is the fix going to be bundled into #66?

@wusatosi
Copy link
Member

wusatosi commented Nov 8, 2024

Would compiler detection + a tool chain file solve this issue?

May relate: #44 (review) ?

@ClausKlein
Copy link
Author

is the fix going to be bundled into #66?

Yes

@steve-downey
Copy link
Member

This has also the advantage of not propagating the Sanitizer settings, coverage compile flags, or CompilerWarnings to the external projects used with FetchContents.

Although for memory and thread sanitizer you must propagate the settings, or the sanitizers don't work.

@steve-downey
Copy link
Member

Would compiler detection + a tool chain file solve this issue?

Toolchain would probably help here. I find it worth it, just to have a single identifier to consolidate the dimensions across the far too many compilers I have locally. I'm lucky I can usually ignore OS, bundling that into the "compiler" choice.
Toolchains are also easier to maintain individually rather than the monolithic presets and user presets files. Those are geared for a small set of common workflows.

@steve-downey
Copy link
Member

Yes

Also answers my question on the PR.

I'll check into what our (mostly self supported) darwin builds are doing in this situation. The default style in house is Lakosian foobar.{cpp/h/t.cpp} triples even if the cpp file is empty other than including the header. It ensures that the header builds, and on some of our older vendor compilers avoided weird link issues with the vtbl not being found. Also made it easier when something was found that did need to be in the cpp file rather than the header.

The newer VERIFY_INTERFACE_HEADER_SETS would fix the broken header problem. Tracking down errors showing up in downstream usage can be frustrating. "Shifting left" finding the typo in the header helps. It's why we run unit tests in our package builds, too.

@wusatosi wusatosi linked a pull request Nov 14, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
5 participants