I am using codelite IDE on windows,
in that when I was trying to compile socket program,
it shows:
warning: ignoring #pragma comment [-Wunknown-pragmas]
for include "WinSock2.h"
#pragma comment(lib,"ws2_32.lib")
First, some clarifications: codelite is not a compiler but an IDE
It uses toolchains (GNU, VC etc)
So when you are saying that "winsock library is not identified by codelite IDE" you actually means: the compiler warns about #pragma
Since you do not provide additional information here (such as the build log, the compiler you are using, codelite version etc) I will take a guess here and would say that you are mixingg the GNU toolchain with VC headers - try to use the WinAPI that comes with MinGW instead.
Looking at the WinSock2.h that comes with GCC for Windows I see only this pragma:
#pragma GCC system_header
Also, .lib libraries are meant to be used by VC but not by GCC
Eran
Related
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++")
I have a Qt project develop on linux, but now I need to compile on windows. I'm having a couple of problems in the migration process.
The first error I'm getting it's:
C:\Qt\Qt5.5.1\Tools\mingw492_32\i686-w64-mingw32\include\c++\bits\c++0x_warning.h:32: error:
#error This file requires compiler and library support for the ISO C++ 2011 standard.
This support is currently experimental, and must be enabled with the
-std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
and this it's how I'm putting it in the .pro of my project
QMAKE_CXXFLAGS += -std=c++11
I also try with
CONFIG += c++11
but the problem continuous.
To give a little more of information, I'm using the MinGW compiler that the Qt Creator install and the extension of my Headers and Sources are: .H and .C (Just in case this have anything to do with the problem, because I've seen that Qt always uses .cpp)
What could be the cause of the problem ?? If something it's unclear or more information it's needed please let me know.
I solve the problem, for me it worked when I change the extension of my sources, I change .C for .cc
it's supposed g++ (tdm-1) 4.7.1 that comes with codeblocks for windows support all C++11 features, std::stoi(str) isnt reconized, same for other c++11 functions. (string header is included).
Do i need to look for another compiler ?
This is due to missing C library functions in MinGW, see the last few comments on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37522
I made some improvements so it is supported in MinGW GCC 4.9 and later, so you could just upgrade to a later TDM build.
Is there a macro that I can #ifdef for to check if librt has been linked to, ie by -lrt with gcc?
No, gcc doesn't have such macro (I've dumped preprocessor macros to check). On Windows with Microsoft compiler you can use _VC_NODEFAULTLIB macro to detect builds without libc reference.
I followed instructions at http://clang.llvm.org/get_started.html
I compiled latest trunk of llvm and clang with MSVC 2010. Now I can compile simple programs with Clang but when I tried to compile this program I got a lot of errors.
Here is program:
#include <algorithm>
int main(){ return 0; }
And here are some of errors:
In file included from hello.cpp:1:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\algorithm:6:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\memory:987:
In file included from C:\Program Files\Microsoft Visual Studio 10.0\VC\include\intrin.h:24:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\immintrin.h:32:
In file included from H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\xmmintrin.h:988:
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1384:22: error: expected expression
return (__m128)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1390:23: error: expected expression
return (__m128i)__in;
^
H:/LLVM/build/bin/Debug/../lib/clang/3.3/include\emmintrin.h:1396:23: error: expected expression
return (__m128d)__in;
^
Complete output from Clang: http://pastebin.com/qi87K8qr
Clang tries to use MSVC headers but it doesn't work. Maybe I should use libc++ or libstdc++ instead, but how to do that?
Note I'm not interested in precompiled clang binaries
Yes, clang simply does not support all of Microsoft's extended C++ syntax, and therefore cannot parse Microsoft's C++ headers which use that syntax. Not only that but Clang also doesn't have complete support for Microsoft's C++ ABI, name mangling, etc. I believe Clang on Windows works alright with C, however.
To use a different C++ standard library instead you can make clang ignore the normal header and library directories with, IIRC, -nostdinc++ and -nostdlib++. Then you can tell clang the include and library directories you want to use (using -isystem or -I or whatever). However I'm not sure whether libc++ or libstdc++ work under those circumstances, since they probably depend on things that the Windows C runtime library does not have.
Chandler Carruth mentioned at Going Native 2013 that there are now alpha builds of clang for Windows with Visual Studio integration. Lots of stuff is broken, for example, streams (so good old hello world won't work). However, there is a lot of effort being put into making clang work on Windows, so expect it to get pretty good pretty fast.
Errors were in the header supplied with clang itself. Looks like it can't handle MMX/SSE types properly. Try to add -msse -msse2 switches to the command line.
I'm using libstdc++ and built clang using VS2012Express for desktop. The cmake string was "Visual Studio 11 Win64" and the essential dirs. are specified using -I argument.
My guess you program could work if I used mingw headers for Windows.