I keep getting this error message while trying to Make this Azteroids project: "c++: error: unrecognized command line option ‘-stdlib=libc++’"
Based on what I've seen online, people are saying it's a Clang flag and the C++11 flag looks different. I mean, I don't disagree, but the instructions for creating the Azteroids executable are pretty simple and CMake seems to recognize C++11 support.
Is this a shortcoming of the cmake system in this project or am I missing a dependency or step? I don't understand. And yes, I've seen the similar questions.
Please see this Pastebin for more both the CMake and Make output.
Nothing in that output indicates that clang is involved here at all. Which is likely the problem.
It would seem that -stdlib=libc++ is a clang flag that your GNU c++ binary does not understand. Those flags are being manually added by the cmake configuration of that project. Which means it will not work without clang. So either remove those flags or install clang and configure cmake to use it.
Related
I've been using a .bat file to build my applications for years. Recently, switched to CMake for it's elegancy and I ran into a situation where I had to guess the flags that I should put into CMake's add_link_options and add_compile_options
Example flags that I've used in my BAT file,
-s WASM=1 --bind -s MODULARIZE=1
And, In CMake this flags have become (After trial and error),
add_compile_options("SHELL: -s WASM=1")
add_link_options("SHELL: --bind")
add_link_options("SHELL: -s MODULARIZE=1")
Honestly, I can't find any information regards flags that add_link_options and add_compile_options supports.
I know what is a linker is but lost when it comes to add_link_options or linker flags.
I'm used to compile everything in single line and now in CMake everything appear to be involve separate steps.
I am not sure what your problem is, but here is a full working sample from a Wasm project that sets project-wide strict mode and disabling of exception support:
if (EMSCRIPTEN)
add_compile_options(-fno-exceptions "SHELL:-s STRICT=1")
add_link_options("SHELL:-s STRICT=1")
endif()
Note in particular that, as it has a [compile+link] marker in the emscripten settings, -s STRICT=1 has to be used both for compiling and for linking, thus it appears in each.
The if(EMSCRIPTEN) around is there because this project can also be built for Windows and Linux.
The options you can pass to the compiler or linker depends on which compiler or linker you use. For example if you fork GCC and add a -Wstackoverflow-copy-pasta option, you can pass that option to add_compile_options(), but other people using standard GCC cannot.
So the answer to your question seems to be, read your compiler and linker documentation.
This is probably not possible, but I still want to ask. I'm using Clangd as an autocompletion engine for VSCode. It works great, but there is one problem.
The official Windows binaries of Clang rely on MSVC standard library headers. If MSVC is not installed, Clang and Clangd complain about missing headers.
There's a flag that makes Clang use MinGW's libstdc++ (--target=x86_64-w64-windows-gnu), which I have to include in compile_commands.json.
This solution works, but it would be nice to have sensible autocomplete even without compile_commands.json.
Is there a way I can tell Clangd to assume --target=x86_64-w64-windows-gnu if there is no compile_commands.json?
At some point after the question was asked, the VSCode Clangd extension started exposing the default flags to the config: "clangd.fallbackFlags": ["--target=x86_64-w64-windows-gnu"].
Is there a way I can tell Clangd to assume --target=x86_64-w64-windows-gnu if there is no compile_commands.json?
From clangd getting started:
compile_flags.txt
If all files in a project use the same build flags, you can put those
flags one-per-line in compile_flags.txt in your source root.
Clangd will assume the compile command is clang $FLAGS some_file.cc.
Creating this file by hand is a reasonable place to start if your
project is quite simple.
Just create compile_flags.txt file with --target=x86_64-w64-windows-gnu.
I've been doing C++ for a long long time, but I come from the land of Windows.
I've been handed a project that uses CMake. I've googled around trying to learn it.
I run cmake .
I assume it always looks for CMakeLists.txt and generates makefiles.
This creates a bunch more cmake files and make files.
I was then instructed to run make package.
I assume package is just a target name that could be anything.
I then get errors:
c++: error: unrecognized command line option ‘-mthumb-interwork’
c++: error: unrecognized command line option ‘-mfloat-abi=hard’
c++: error: unrecognized command line option ‘-mfpu=neon’
I think those are due to the fact that I am trying to compile for a different architecture then the one I am on. I assume all the cmake files would set that up correctly for me. I also assume that nothing there is proprietary.
I see the line in the CMakeLists.txt
SET(CMAKE_CXX_FLAGS "-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -std=c++11 -O3")
If I look at the official cmake documentation, it says, and I quote
"Flags for all build types." ....Not very helpful
I am thinking it isn't using the correct compiler, but I also don't see where in the CMakeLists.txt the compiler is specified at all.
The question is:
Why would these flags be unrecognized?
In the Linux world, it's often assumed that you don't need to specify the compiler by name; instead you arrange for c++ to refer to the compiler. That may involve setting PATH, creating a shell alias or a symbolic link.
Apparently you already did so, as your compiler is being called and is complaining about standard GCC flags - clearly your compiler isn't GCC.
The CMakeLists.txt file however is very much assuming it's intended for GCC. Don't blame CMake for that. CMake is the tool, CMakeLists.txt are project-specific instructions. This is a problem of whoever created the particular CMakeLists.txt file.
There's no easy fix. There is a real possibility that the -mfpu=neon option to gcc was necessary for the program, and it's anyone's guess what you'll need on the other compiler.
I am working with a very inconvenient software, and it doesn't support clang. So, I am required to change my cmake compiler and as I read almost everywhere, and here How can I make CMake use GCC instead of Clang on Mac OS X?, I tried :
cmake -DCMAKE_CXX_COMPILER=/usr/bin/g++
However, I am still getting this error
CMake Error at CMakeLists.txt:59 (message):
GAMBIT does not support the Clang compiler. Please choose another
compiler.
-- Configuring incomplete, errors occurred!
Any suggestion, please?
I've found setting environment variables CC and CXX before running CMake for the first time peferrable to messing with CMAKE_CXX_COMPILER. Also note that it's probably a good idea to set both. So get into an empty binary directory and run this:
CC=/usr/bin/gcc CXX=/usr/bin/g++ cmake ...
Also make sure that /usr/bin/gcc is really GCC and not e.g. a symlinked or otherwise disguised Clang (I believe such setup can exist in the MacOS world).
You probably need to set CMAKE_C_COMPILER as well, that is:
cmake -DCMAKE_CXX_COMPILER=/usr/bin/g++ -DCMAKE_C_COMPILER=/usr/bin/gcc
Indeed, looking at Gambit source code, it seems it's mostly C.
Personally, I usually like to set both, just in case.
I just installed YCM on CentOS 7. I am now at the step of generating a ".ycm_extra_conf.py" equivalent of the file for my project, which is a nested directory of c++ files, uses Scons build system and g++ (with -std=c++98) to compile the c++ files.
I have few questions:
Are the contents of the "flags" variable in ".ycm_extra_conf.py"
file the flags that are passed to the project compiler, in my case
the g++ compiler by the scons build system?
If answer to question 1 is yes, are these same flags then passed to
clang when YCM compiles the files? If so, is YCM compiling or more
technically processing the c++ files in the project to use for
semantic completion?
If answer to question 2 is yes, then I am guessing the flags I state in
the "flags" variable will not work for clang, as they are applicable to
g++. Should I do a conversion/mapping of the flags to clang?
Does YCM use clang to only front-end compile the files to produce the
AST to use for semantic completion?
Sorry about the naive questions, I am very new to YCM. Any help/guidance would be very appreciated.
Regards and thank you,
Ahmed.
The easiest way to get autocompletion working in vim with ycm is bear:
https://github.com/rizsotto/Bear
Install it and then just run:
bear scons
and you'll get your compilation database that makes ycm happy.