Eclipse NEON.1 4.6.1 with CDT 9.1.0, g++ 5.4.0
It doesn't recognize all c++11/14 features. It does recognize keywords like auto and nullptr. It doesn't however recognize things coming from headers which depend on the correct symbols being defined.
For instance when including <memory> it recognizes old symbols like std::auto_ptr not knew ones like std::shared_ptr. These newer features are within an #if __cplusplus >= 201103L.
I can get it to work for a standard eclipse project by setting the dialect option but I need it to work with an autotools based project which doesn't have a dialect setting.
I have the actual compilation of the program working using AM_CXXFLAGS automake variable. To get it to work for the indexer I went in eclipse to Project properties > C/C++ General > Preprocessor Include Paths, Macros
Then to the providers tab and added -std=c++14 option to the command for the CDT GCC Built-in Compiler settings. I also moved that provider to the top of the list. On the entries tab you can see the actual value of the __cplusplus define. Before I added the -std=c++14 switch it was wel below the required 201103L after I added the switch it was well above.
Found out what the problem was. When I added the -std=c++14 option in the command to get the compiler spec on the provider tab I added them for the "Debug" configuration as I was using that configuration. Turned out that the indexer was set to always use the "Build" configuration. After I added the setting also for the "Build" configuration and reindexed the errors went away.
Related
I have a cc_library (tbb) that requires the compiler flag -mwaitpkg on some compilers (Clang) to compile successfully. At the same time, there are older versions of GCC (4.9) that do not know this flag, and therefore the compilation via GCC 4.9 leads to an error:
gcc: error: unrecognized command line option '-mwaitpkg'
In a more advanced Bazel setup, I guess one would work around this using hermetic toolchains. This way every toolchain could provide its own set of compiler flags. Nevertheless, I do not want to enforce any specific toolchain and I am not sure if this is the right way to go (move copts to toolchain?).
Also introducing a config would be a way to solve this problem. E.g. bazel build --config=waitpkg //.... But this would require that a user is aware of this config and also knows the details of using waitpkg.
What is a proper "Bazel-way" to handle different compiler flags for different compilers?
The flag '-mwaitpkg' is supported by GCC version 9.3, Clang* 12, and newer versions of those tools.
If you build Bazel with earlier versions of GCC, you should remove the flag otherwise it gives compilation errors.
I am trying to build my project and run an executable in a different machine where I can see thread related issues (if exist). I am using VS2019 and providing -fsanitize=thread -fPIE -pie -g options in the Configuration Properties->Debugging->Command Arguments.
When I run the .exe file, I don't see any generated file which I suppose should have been generated.
Am I providing wrong arguments to the compiler or what is wrong here?
Configuration Properties->Debugging->Command Arguments is a wrong place for compiler options. They should go to Configuration Properties->C/C++->Command Line->Additional options
These options you want to pass are not supported neither by MSVC compiler (Visual C++), nor by clang-cl (Clang under Windows that mimic MSVC)
MSVC does not have ThreadSanitizer at all. (-fsanitize=address is available though)
To build a C library with Visual Studio, the CMake command
set(WINDOWS_EXPORT_ALL_SYMBOLS ON)
saves me from adding __declspec(dllexport) or __declspec(dllimport) in front of function declarations; explicit import/export symbols are only required for global variables.
Under MinGW (read: either MinGW or its recommendable replacement Mingw-w64) this does not work. Linking applications (also built with MinGW) to my library failed until I had pasted import/export symbols in front of each function. Whereas the long answer https://stackoverflow.com/a/32284832/1017348 suggests the contrary: no need for import/export symbols under MinGW. Is that answer right? How then to get rid of the need for import/export symbols?
I just encountered the same problem. After poking through CMake source code, the fix that worked for me was to also add:
set( CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS 1 )
CMake says:
This property is implemented only for MS-compatible tools on Windows.
CMake enables this capability by setting CMAKE_SUPPORT_WINDOWS_EXPORT_ALL_SYMBOLS in each "Platform" file in <cmake install>/Modules/Platform that they know supports it. However, CMake doesn't model MinGW as a "Platform". Instead you just pick "Windows Makefile", "Windows Ninja", etc. and manually set the C/C++/Fortran compilers to point to the MinGW gcc compilers. Ideally CMake should recognize when the OS is Windows and the compiler is gcc and set this for us, but for now we can help it by setting it ourselves.
Incidentally CMake implements this feature with a hidden cmake -E __create_def <output-def> <input-list-of-obj-files> command. I previously thought of adding a custom rule to run that command. Though as it starts with __, it's meant for internal use and might change from one release to the next.
I have a C++ project which uses CMake as its build system in Visual Studio 2017 Enterprise. According to the documentation, I have to link using /LTCG and /GENPROFILE. In CMake, this seems to equate to setting the variable CMAKE_EXE_LINKER_FLAGS:
set(LINKER_FLAGS, "/LTCG /GENPROFILE")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${LINKER_FLAGS}")
Furthermore, since my application requires command line arguments, I had to define them in the launch.vs.json as seen in this answer.
Now if I run the application's x64-Release profile, it successfully completes in a normal, non-delayed Release build fashion. No .pgd has been generated which means that my passed linker flags probably have been ignored.
Another try was adding additional CMake linker flag variables:
set(LINKER_FLAGS, "/LTCG /USEPROFILE")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${LINKER_FLAGS}")
set(CMAKE_STATIC_LINKER_FLAGS "${CMAKE_STATIC_LINKER_FLAGS} ${LINKER_FLAGS}")
This also didn't work. Specifying /USEPROFILE afterwards did not generate a different binary. Also, the runtimes are roughly equivalent. There is also no indication on the command line that a profile has been generated or used.
What am I doing wrong here?
My cmake project shall compile c++14 code. It also uses the CMakeLists.txts included from its external libraries (which are git submodules in my project). The build fails on macOS Sierra (cmake 3.6.2) because the default STL of clang is old and doesn't handle c++11. As far as I understand, there are two STLs shipped with clang: libstdc++ (from gcc) (default) or libc++. So if I add the -stdlib=libc++ option to cmake, the source compiles:
add_compile_options( "$<$<COMPILE_LANGUAGE:CXX>:-std=c++14>" )
add_compile_options( "$<$<COMPILE_LANGUAGE:CXX>:-stdlib=libc++>" )
But then it fails at link time because it tries to use libstdc++ for linking. How do I specify in cmake that the new STL libc++ shall be used for the whole build process?
PS: What is the rationale behind clang using the gcc STL by default if it is too old? Could I permanently specify which STL it shall use? Or am I doing something completely wrong (could some of my subprojects silently force gcc?)?
You should rely on CMake to handle compile options. Just specify the wanted standard version:
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
target_compile_features can also be used to require particular features of the standard (and implicitly ask CMake to set the adequate configuration). More information here.
EDIT
You figured out the solution, you also had to remove the following line in the CMakeLists of Ogred3D:
set(CMAKE_OSX_DEPLOYMENT_TARGET 10.7)
Removing it prevented CMake to add the flag mmacosx-version-min=10.7 causing the error.
I suppose, you also need to pass that flang to the linker in the clang case:
link_libraries("-stdlib=libc++")