CMake target_compile_features unordered_map - c++11

I'm trying to introduce using CMake to build my C++ project. When I run make I get an error :
[ 11%] Building CXX object CMakeFiles/game.dir/InputHandler.cpp.o
In file included from /usr/include/c++/5/unordered_map:35:0,
...
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support...
I realise this is because CMake is not invoking C++11 when it needs to in order to enable the use of the unordered_map. After googling I know I need to use target_compile_features() in my CMakeLists.txt. But I can't find anywhere which gives me the syntax/arguments I need to use, there's just examples e.g. on the CMake page it gives :
add_library(mylib requires_constexpr.cpp)
target_compile_features(mylib PRIVATE cxx_constexpr)
But I don't need cxx_constexpr, I don't even know what that is. I need unordered_map.
Can anyone tell me the syntax I need to use please, preferably giving me some sort of reference to valid values to pass into that function.

std::unordered_map is part of the STL, it isn't a language keyword like constexpr or override, etc. CMake doesn't provide compile features for STL functionality (that would be an overwhelming task to implement!). In your case, you really just want to tell CMake that you need C++11. This article provides all the details you should need on this topic, but to summarise it for this particular question, adding the following near the top of your CMakeLists.txt file should give you what you need:
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

Related

Does Dev-Cpp 5.11 support C++ 11?

I struggled to find a clear answer on the first Google page.
I have troubles understanding the term "Language standard". I mean, the new standard should be implemented on a software level, right? It's not just a list of things discovered that users can now do, right?
I use delegating constructors, get a warning:
[Warning] delegating constructors only available with -std=c++11 or -std=gnu++11
Though things seem to work the way I want them to. Is such warning critical? If so, how do I get rid of it?
Dev-Cpp is just IDE (frontend) for coder and behind it sits MinGW with GCC 4.9.2 as compiler*. So every time you click "Run" or "Build" it is GCC to do the dirty job. GCC by default uses C++03 standard and to use newer one you have to tell it explicitly via compiler flag -std=c++11. You can change it in Tools->Compiler Options->Settings->Code generation->Language standard (-std).
I am not sure why delegating constructors could work without C++11 (probably some GCC feature), but for sure you will not be able to use C++11 libraries without -std=c++11. It will also get rid of the warning.
(* Assuming you used default Dev-C++ installer.)

how to use boost libraries in mingw which are built with msvc

I built boost libraries with msvc. And I want to link to my program using mingw. As the title asked, how can I achieve that?
When I try to link the boost libraries. The compiler suggests that it can't find symbols of the boost libraries.
Quoting the mingw wiki here:
Object files and static libraries created with different compilers [...] often cannot be linked together. This issue is not specific to MinGW: many other compilers are mutually incompatible. Build everything from source with the same version of the same compiler if you can.
It is stated in the same page that if you want, you may use dynamic (shared) libraries from different compilers if you provide a C interface for the library you want to use. Then your program would use this interface (C wrapper library) to communicate with Boost, by including the header for this interface library with extern "C". Example of doing this can be found here.
In your case, however, this would not be preferable as you would have to expose everything you want to use from Boost one by one in the C interface that you would write yourself. You might find it much easier just compiling your libraries with the same compiler you are compiling your program with.

What's the relationship between "gcc linking" and "ld linking"?

It's said that linux loader is /usr/bin/ld, but usually we use gcc/g++ to link libraries and executables, we barely use "ld".
The last time I used "ld" manually was when I was learning linux assembly, the only way to generate executable is to ld a .o file to generate executable directly without any library.
My question is, is gcc/g++ containing some function wrappers of "ld", because raw "ld" is too difficult to use? Or we should never use "ld" explicitly for c/c++ program linking, because of blablabla?
gcc supplies a few default options to ld.
ld doesn't know anything about C++, or any other language. ld has no idea what libraries your code needs to link with. If you try to link your compiled C++ code with ld directly, it'll bail out on you, since ld, by itself, has no idea where it can find libstdc++, gcc's C++ runtime library. Do you use strings? vectors? Most of that is template code that gets compiled as part of your object module. But there are a still few precompiled bits, in libstdc++, that need to be linked with.
When you give your compiled code to gcc to link, gcc will be courteous enough to pass all your files along to ld, and tell ld which libraries, in addition to any ones you explicitly specify.
You can link with ld directly, if you want to, as long as you specify the same libraries and link option gcc uses. But why would you want to do that? Just use gcc to link your gcc-compiled code.
You shouldn't attempt to directly use ld to link a C++ program because you need to know the implementation detail of where the static part of the C++ runtime library is located. g++ knows these implementation details, such as where to find the file libstdc++.a. If you tried to use ld directly, you would have to supply all these "missing" static libraries.
My question is, is gcc/g++ containing some function wrappers of "ld"
That's right.
because raw "ld" is too difficult to use?
Well, not really; you could use it yourself without too much trouble, but it's convenient to manage the entire build process through a single executable, with a single suite of flags, and often with a single command.
It's also likely that you'd have to provide absolute paths to some runtime libraries (e.g. libstdc++.a) yourself if you bypassed the wrapper (though I haven't tested this).
Or we should never use "ld" explicitly for c/c++ program linking, because of blablabla?
You're free to do so if you want. The only reason people might raise their eyebrows is to ask why you're not doing it in the conventional manner. If you have a good reason to invoke ld directly, rather than going through g++ and passing through any linker flags that way, then go right ahead!

#pragma comment(lib, "xxx.lib") equivalent under Linux?

I have a static library file called libunp.a, I do know I could use gcc -lunp xx to link to the library.
I could use #pragma comment(lib,"xxx.lib") to tell the Microsoft C/C++ compiler to include the library; how could I do it under Linux/GCC?
There doesn't seem to be any mention of any equivalent pragmas in the GCC manual's page on pragmas.
One reason I saw for GCC not supporting linking in source code was that sometimes, correct linking depends on link order; and this would require you to make sure that the linking order happens correctly no matter the order of compilation. If you're going to go to that much work, you may as well just pass the linker arguments on the command line (or otherwise), I suppose.
Libraries should be specified during the linking step. Such information simply
doesn't belong inside a translation unit. A translation unit can be preprocessed,
compiled and assembled even without a linking stage.
Simply because #pragma comment(lib,"xxx.lib") is in the source file does not mean the compiler consumes it. In fact, it goes in as a comment and is subsequently used by the linker. Not much different than *nix.
Use this GCC flag to generate an error for unknown pragmas. It will quickly tell you if the compiler understands it.
-Werror=unknown-pragmas

Cross compile Boost 1.40 for VxWorks 6.4

I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for __ppc but my compiler defined __ppc__ (or vice versa, can't remember).
touch empty.cpp
ccppc -dD -E empty.cpp
That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
Try also adding
threadapi=pthread
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.

Resources