Using clang with codeblocks on Windows 7 - c++

I have managed to build clang on Windows 7 using Visual Studio 210 and now I like to use it with the codeblocks IDE. So I copied the clang executables into the mingw bin\ folder and updated the codeblock's compiler settings to use clang instead of gcc.
But when I compile the hello world example I get the following errors:
||=== clang_test, Debug ===|
obj\Debug\main.o:c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\system_error|447|undefined reference to `std::iostream_category()'|
obj\Debug\main.o:c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdexcept|170|undefined reference to `std::exception::exception(char const* const&)'|
||=== Build finished: 2 errors, 0 warnings ===|
I guess I have to use clang's header files but how to I accomplish that?
Thanks!

UPDATE
MSYS2 packages are available for clang on 32-bit and 64-bit, and from what limited testing I did it seems to work quite well. The compiler can be used from outside the MSYS2 environment.
On how to install MSYS2, see here. Then just run
pacman -Sy mingw-w64-x86_64-clang
or
pacman -Sy mingw-w64-i686-clang
after updating MSYS2 to install Clang.
The patches used in that package (if you want to build LLVM/Clang yourself) are located here.
old reply follows, slightly out of date
If you want to use Clang on Windows for C++, your only option currently is to use (or build yourself) Clang with/for MinGW(-w64).
Lucky for you, I provide packages:
Clang 3.2
GCC 4.6.3 dw2
Unzip both to the same directory and add mingw32-dw2/bin to PATH, or point Codeblocks to it. You will be limited to GCC 4.6's libstdc++. Clang 3.2's C++11 language support is fully functional though.
Note that Clang expects GCC style options, so I suggest modifying the Codeblocks GCC build process and replacing g++ with clang++ and gcc with clang.

clang does not support MSVC C++ ABI yet so C++ code cannot be compiled correctly.
Update: As of December 2014, clang does support MSVC except (heh) exceptions. To compile code you will have to do
clang-cl.exe /D_HAS_EXCEPTIONS=0 foo.cpp
If you want to use clang.exe directly:
clang++ -target i686-pc-windows-msvc -D_HAS_EXCEPTIONS=0 foo.cpp -o foo.exe
etc.
For up to date status of MSVC support see http://clang.llvm.org/docs/MSVCCompatibility.html

My CodeBlocks build logs show command lines as
clang++.exe -fno-ms-compatibility -fno-use-cxa-atexit -IC:\mingw\include\c++\4.7.0 -IC:\mingw\include\c++\4.7.0\x86_64-w64-mingw32 -IC:\mingw\include\c++\4.7.0\backward -IC:\mingw\include -c C:\Users\Vipul\Documents\Hello.cpp -o C:\Users\Vipul\Documents\Hello.o
ld.exe -oC:\Users\Vipul\Documents\Hello.exe C:\Users\Vipul\Documents\Hello.o -m i386pep -Bdynamic -Lc:\mingw\lib c:\mingw\lib\crt2.o c:\mingw\lib\crtbegin.o -lstdc++ -lmingw32 -lgcc_s -LC:\Windows\SUA\opt\gcc64\lib\gcc\x86_64-pc-interix6\4.6.0 -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 c:\mingw\lib\crtend.o
and I can run the program. I've built Windows clang with VSExpress. If compilation or link is causing errors on your end, then comparing our command lines might help isolate the issue.

Related

How to make "clang on Windows" use LLVM libcxx instead of MSVC C++ library? [duplicate]

Does libc++ support to be referenced/included and compiled on Windows with Clang/LLVM as native? For native, I mean no dependence on mingw and cygwin. I didn't find much doc on this but I believe it should be supported as clang for Windows has been released for a long time.
Just an update. There is experimental support now (early 2018):
https://libcxx.llvm.org/docs/BuildingLibcxx.html#experimental-support-for-windows
(from the link)
Assming you have Ninja, and libcxx/llvm both checked out, libcxx can be compiled via
> cmake -G Ninja ^
-DCMAKE_MAKE_PROGRAM=/path/to/ninja ^
-DCMAKE_SYSTEM_NAME=Windows ^
-DCMAKE_C_COMPILER=clang-cl ^
-DCMAKE_C_FLAGS="-fms-compatibility-version=19.00 --target=i686--windows" ^
-DCMAKE_CXX_COMPILER=clang-cl ^
-DCMAKE_CXX_FLAGS="-fms-compatibility-version=19.00 --target=i686--windows" ^
-DLLVM_PATH=/path/to/llvm/tree ^
-DLIBCXX_ENABLE_SHARED=YES ^
-DLIBCXX_ENABLE_STATIC=NO ^
-DLIBCXX_ENABLE_EXPERIMENTAL_LIBRARY=NO ^
\path\to\libcxx
> /path/to/ninja cxx
As of 4/23/18, it will install into Program Files (x86) even if compiled for x86-64... (which can be done by changing i686 to x86_64 in the above).
Update in November 2020: I now use a package called llvm-mingw.
This package includes the clang compiler toolchain with wrappers to support various gcc style executables (e.g. gcc.exe, g++.exe, x86_64-w64-mingw32-gcc.exe) and can be used out of the box to compile against the mingw libc++ (you don't have to install mingw separately, the mingw libraries come with the package).
llvm-mingw is still young but has most features of mingw-w64. Features that are not implemented are:
lld linking to a dll (it's a feature of gnu ld, but not the llvm implementation)
There is no python wrapper for lldb so many IDEs can't use the debugger. Visual Studio Code seems to have it's own linkage so LLDB soes work with VS Code. People are working on this now.
Releases are available at the authors github repo. I have a binary installer available at my winlua.net site.
One can build and install libc++ together with clang in Windows by setting LLVM_FORCE_BUILD_RUNTIME cmake's variable to ON. Here is an example:
cmake -Wno-dev -G Ninja
-DCMAKE_INSTALL_PREFIX=c:\clang
-DLLVM_ENABLE_Z3_SOLVER=ON
-DLLVM_ENABLE_PROJECTS='clang;clang-tools-extra;compiler-rt;libcxx;lld'
-DLLVM_FORCE_BUILD_RUNTIME=ON
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_COMPILER=clang-cl
-DCMAKE_CXX_COMPILER=clang-cl
-DCMAKE_CXX_FLAGS='/DWIN32 /D_WINDOWS /W3 /GS- /GR /EHsc /D_CRT_SECURE_NO_DEPRECATE /D_SECURE_SCL_DEPRECATE=0 /D_SECURE_SCL=0 /D_HAS_ITERATOR_DEBUGGING=0 /DSTRSAFE_NO_DEPRECATE'
-DCMAKE_CXX_FLAGS_RELEASE='/MD /clang:-march=native /clang:-mtune=native /clang:-O3 /clang:-g0 /DNDEBUG'
-DCMAKE_C_FLAGS='/GS- /DWIN32 /D_WINDOWS /W3 /D_CRT_SECURE_NO_DEPRECATE /D_SECURE_SCL_DEPRECATE=0 /D_SECURE_SCL=0 /DSTRSAFE_NO_DEPRECATE'
-DCMAKE_C_FLAGS_RELEASE='/MD /clang:-march=native /clang:-mtune=native /clang:-O3 /clang:-g0 /DNDEBUG'
..\llvm-project\llvm
However, there is a catch. Clang driver in Windows still doesn't support libc++, so you have to manually add the header files directory and c++.lib, if you want to use libc++. If you take a look at the Clang's driver source code, there is a line left there 9 years ago:
void MSVCToolChain::AddClangCXXStdlibIncludeArgs(const ArgList &DriverArgs,
ArgStringList &CC1Args) const {
// FIXME: There should probably be logic here to find libc++ on Windows.
}
It's not a rocket science to add the support, just shows the level of interest to support Windows by the authors.
An example of using libc++ (after compiling and installing clang with the above cmake example):
clang++ -isystem 'c:\clang\include' -isystem 'c:\clang\include\c++\v1' -c .\test.cpp -o test.o
clang++ -fuse-ld=lld test.o -o test.exe -L'c:\clang\lib' -lc++

host_config.h:unsupported GNU version! gcc versions later than 4.9 are not supported [duplicate]

I struggle with Caffe compilation. Unfortunately I failed to compile it.
Steps I followed:
git clone https://github.com/BVLC/caffe.git
cd caffe
mkdir build
cd build
cmake ..
make all
Running make all fails with the following error message:
[ 2%] Building NVCC (Device) object src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o
In file included from /usr/include/cuda_runtime.h:59:0,
from <command-line>:0:
/usr/include/host_config.h:82:2: error: #error -- unsupported GNU version! gcc 4.9 and up are not supported!
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
^
CMake Error at cuda_compile_generated_im2col.cu.o.cmake:207 (message):
Error generating /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/./cuda_compile_generated_im2col.cu.o
Software version:
OS: Debian.
gcc version: 5.3.1.
nvcc version: 6.5.12.
cat /proc/driver/nvidia/version result:
NVRM version: NVIDIA UNIX x86_64 Kernel Module 352.63 Sat Nov 7 21:25:42 PST 2015
GCC version: gcc version 4.8.5 (Debian 4.8.5-3)
Attempts to solve the problem
1st try
Simple solutions are often best ones, so (as suggested here) I tried to comment out macro checking gcc version from /usr/include/host_config.h (line 82). Unfortunately it doesn't work and compilation fails badly:
1 catastrophic error detected in the compilation of "/tmp/tmpxft_000069c2_00000000-4_im2col.cpp4.ii".
2nd try
I tried to run:
cmake -D CMAKE_CXX_COMPILER=g++-4.8 ..
make
but it fails with exactly the same error message (even though g++-4.8 should be accepted).
3rd try
I've found similar problem (though not related to Caffe) and I tried to solve it as suggested in the accepted answer.
What I did:
I've ran grep -iR "find_package(CUDA" caffe command and found Cuda.cmake file which has find_package(CUDA 5.5 QUIET) in line 225.
I added set(CUDA_HOST_COMPILER /usr/bin/gcc-4.8) to Cuda.cmake, line before line: find_package(CUDA 5.5 QUIET).
I removed everything from build directory and ran cmake and make again - with and without -D CMAKE_CXX_COMPILER=g++-4.8.
Unfortunately result is exactly the same. Caffe probably overwrites it somehow - I didn't figure it out how.
make VERBOSE=1 2>&1 | grep -i compiler-bindir returns nothing.
What's interesting, make VERBOSE=1 prints command that fails, which is:
/usr/bin/nvcc -M -D__CUDACC__ /mydir/caffe/src/caffe/util/im2col.cu -o /mydir/caffe/build/src/caffe/CMakeFiles/cuda_compile.dir/util/cuda_compile_generated_im2col.cu.o.NVCC-depend -ccbin /usr/bin/cc -m64 -DUSE_LMDB -DUSE_LEVELDB -DUSE_OPENCV -DWITH_PYTHON_LAYER -DGTEST_USE_OWN_TR1_TUPLE -Xcompiler ,\"-fPIC\",\"-Wall\",\"-Wno-sign-compare\",\"-Wno-uninitialized\",\"-O3\",\"-DNDEBUG\" -gencode arch=compute_20,code=sm_21 -Xcudafe --diag_suppress=cc_clobber_ignored -Xcudafe --diag_suppress=integer_sign_change -Xcudafe --diag_suppress=useless_using_declaration -Xcudafe --diag_suppress=set_but_not_used -Xcompiler -fPIC -DNVCC -I/usr/include -I/mydir/caffe/src -I/usr/include -I/mydir/caffe/build/include -I/usr/include/hdf5/serial -I/usr/include/opencv -I/usr/include/atlas -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/mydir/caffe/include -I/mydir/caffe/build
when I add --compiler-bindir /usr/bin/gcc-4.8 flag manually, it prints error:
nvcc fatal : redefinition of argument 'compiler-bindir'
which may be related to this bug report.
Edit: I didn't notice that --compiler-bindir and -ccbin are the same options, and the latter is already set in above command that failed. When I changed -ccbin /usr/bin/cc to -ccbin /usr/bin/gcc-4.8 in above command that failed, it completes successfully. Now I need to find option in Caffe's CMake file that overwrite -ccbin in all subsequent Caffe's CMakes. Looking at cmake/Cuda.cmake:252:list(APPEND CUDA_NVCC_FLAGS ${NVCC_FLAGS_EXTRA} seems to be good way to go.
How can I successfully complete my compilation? Any help is appreciated.
Related SO questions:
host_config.h:unsupported GNU version! gcc versions later than 4.9 are not supported.
CUDA 6.5 complains about not supporting gcc 4.9 - what to do?.
cmake -D CUDA_NVCC_FLAGS="-ccbin gcc-4.8" .. && make causes successful compilation.
Now another problem showed up: linking Google's libgflags or libprotobuf fails probably due to fact that it was compiled with newer gcc version but it's not related to asked question.
My machine runs Ubuntu 15.10, and my default compiler version is gcc 5.2.1 .
Commenting out the #error directive in line 115 of file
/usr/local/cuda-7.5/include/host_config.h
(or whatever the path on your system is) did the trick for me. Caffe compiled fine, all tests ran smoothly.
On the other hand, if one chooses to ignore this and proceed to compile part of the project with one compiler version, part of the project with another (for me it was gcc-4.8 and gcc-5.2.1), linking problems will arise. The linking problems of protobuf and libgflags another answer mentions are not unrelated to this.

Did upgrading to Ubuntu 14.04 break the c++ linker?

I have a Linux-based application, running under Ubuntu 12.04 LTS, that compiled, linked, and ran with no problem.
I recently upgraded my Ubuntu to 14.04 LTS and encountered problems compiling and linking the app.
The compilation problems were solved by manually modifying my local copy of Boost 1.48 in two files (include/boost/config/stdlib/libstdcpp3.hpp and include/boost/thread/xtime.hpp). At this point the app compiled successfully.
The problem I have is that the linkage fails with the error message:
c++: error: unrecognized command line option ‘-Wl’
I use CMake to enable compiling the app on multiple platforms. Here is the linker script generated by CMake. Note that the "-Wl" options are now inexplicably unrecognized by /usr/bin/c++:
/usr/bin/c++
-fno-stack-protector
-g
-Wl
CMakeFiles/Project.dir/main.cpp.o
CMakeFiles/Project.dir/TestCallback.cpp.o
CMakeFiles/Project.dir/utils.cpp.o
CMakeFiles/Project.dir/Request1.cpp.o
CMakeFiles/Project.dir/Response1.cpp.o
CMakeFiles/Project.dir/TextChatRequest.cpp.o
CMakeFiles/Project.dir/TextChatResponse.cpp.o
-o
/home/user/private/Project/Project_Release_1_2_Codename/Build/bin/Debug/Project
-L/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib
-L/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib
-L/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib
-L/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug
-L/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
-rdynamic
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libAPI.a
/home/user/private/Project/Project_Release_1_2_Codename/lib/libUbuntu32/Debug/libInternals.a
-lboost_thread
-lboost_system
-lboost_filesystem
-lboost_program_options
-ltaglib
-lJSON
-lpthread
-Wl,-Bstatic
-lsqlite3
-Wl,-Bdynamic
-ldl
-Wl,-rpath,/home/user/Libraries/Ubuntu32_12.04/boost_1.48/lib:/home/user/Libraries/Ubuntu32_12.04/SqlLite_3.6/lib:/home/user/Libraries/Ubuntu32_12.04/taglib_1.7/lib:/home/user/Libraries/Ubuntu32_12.04/JSON_1.0/lib/Debug:/home/user/private/Project/Project_Release_1_2_Codename/Build/../lib/libUbuntu32/Debug
Here is version information for the software I'm using:
Ubuntu:
14.04.1 LTS (trusty)
c++ compiler/linker:
(Ubuntu 4.8.2-19ubuntu1) 4.8.2
CMake:
Version 2.8.12.2
Why doesn't the linker recognize "-Wl" commands? Did my upgrade to 14.04 LTS modify the linker software libraries? How can I get my app back up and linking?
On line 4 of the command you have -Wl without any actual linker options.
https://gcc.gnu.org/gcc-4.7/porting_to.html
Right at the top of this page is the following:
Earlier releases did not warn or error about completely invalid
options on gcc/g++/gfortran etc. command lines, if nothing was
compiled, but only linking was performed. This is no longer the case.
For example,
gcc -Wl -o foo foo.o -mflat_namespace
Now produces the following error
error: unrecognized command line option ‘-Wl’
error: unrecognized command line option ‘-mflat_namespace’
Invalid options need to be removed from the command line or replaced by something that is valid.
12.04 LTS packaged GCC 4.6, you've now jumped to 4.8 and -Wl on its own is no longer a valid option (or rather it never was, GCC is just more pedantic now).
As mentioned by others previously, it indeed turned out that my CMake script was injecting a lone, solitary, seemingly unnecessary "-Wl" via the CMAKE_EXE_LINKER_FLAGS setting:
if(LINUX)
set(THIRDPARTY_LIBS boost_thread boost_system boost_filesystem boost_program_options taglib JSON)
set(OS_LIBS pthread sqlite3.a dl)
set(CMAKE_EXE_LINKER_FLAGS "-Wl")
set(PREPROCESSOR_DEFINITIONS ${PREPROCESSOR_DEFINITIONS};/DTAGLIB_STATIC)
endif(LINUX)
When I removed this setting, the build succeeded. This oversight has been around a while, with the earlier version of gcc not minding. The latest gcc, however, is more pedantic and flagged it as an error.

Getting a Botan library test program to compile under Windows 7 (MinGW, Code::Blocks)

I have been trying in vain to get this test program to compile
#include <botan/botan.h>
int main()
{
Botan::LibraryInitializer init;
}
I have downloaded library source from the website. I ran configure.py, which ran fine.
I then attempted to run MinGW-make
This is the error I got
c:\Botan-1.11.7>mingw32-make
g++ -m64 -pthread -fPIC -fvisibility=hidden -std=c++11 -D_REENTRANT -fstack-pro
tector -O3 -momit-leaf-frame-pointer -Wall -Wextra -Wstrict-aliasing -Wstrict-ov
erflow=5 -Wcast-align -Wmissing-declarations -Wpointer-arith -Wcast-qual -Wold-s
tyle-cast -Wzero-as-null-pointer-constant -Ibuild\include -c C:\Botan-1.11.7\src
\lib\algo_base\scan_name.cpp -o build\obj\lib\src_lib_algo_base_scan_name.obj
C:\Botan-1.11.7\src\lib\algo_base\scan_name.cpp:1:0: warning: -fPIC ignored for
target (all code is position independent) [enabled by default]
C:\Botan-1.11.7\src\lib\algo_base\scan_name.cpp:1:0: sorry, unimplemented: 64-bi
t mode not compiled in
mingw32-make: *** [build\obj\lib\src_lib_algo_base_scan_name.obj] Error 1
I searched Google and any available forum I could find. I found prebuilt libraries for windows in a hidden folder on their site. However the package contained lib and dll files and not .a files which MinGW requires. I tries to use a program LIB2A which created a .a file. I have added this file into my code::blocks linker options. I also included the include folder.
When I try to compile I get this error.
C:\botan\include\botan\init.h|41|undefined reference to `_imp___ZN5Botan18LibraryInitializer10initializeERKSs'|
It seems like it cannot see the library with function definitions, but I am lost on where to go from here.
mingw32-make has the -m64 flag set, which means it's trying to build a 64 bit library. To build a 64 bit library, you'll need to get MinGW-w64.
When you ran configure.py, it likely set up your MakeFile to build a 64 bit library. You'll want to check what options are set in its output. This includes the option to build 32 bit or 64 bit. Either way, you'll want some variant of this: python configure.py --os=mingw --cc=gcc
This question had a similar error, and suggested using MinGW-w64, which will allow you to build a 64 bit library: Building 64 bit dll with MinGW 32 bit in Eclipse
In order to build with mingw32-make off the command line, you'll need to also add the MinGW-w64 bin directory to your Windows path, and likely remove the Code::Blocks packaged MinGW from your path to avoid conflicts. You'll still use mingw32-make to build the library with MinGW-w64; even though it's named mingw32-make, it will build 64 bit.
If you decide to build the library 64 bit, you'll need to build your application 64 bit as well, so you'll want to set up MinGW-w64 for Code::Blocks. To set MinGW-w64 up in Code::Blocks, see this question: Setting up MingW and Code::Blocks in Windows 8 64 bit.

Regex Boost library linking in release mode warns "duplicate section has different size" when using mingw-w64 toolchain

When linking my project in the release mode I am getting the following warning:
myProject-libs/release/libboost_regex-mt-s-1.50.0.a(cpp_regex_traits.o): duplicate section `.data$_ZZN5boost16cpp_regex_traitsIcE21get_catalog_name_instEvE6s_name[boost::cpp_regex_traits<char>::get_catalog_name_inst()::s_name]' has different size
I suspect that the cause could be that the boost library is compiled with different options than I use for my project, but I don't know how to find the difference (boost didn't output these options during the build).
In order to compile the boost for win32 on Ubuntu 12.04 I used this procedure:
tar jxf boost_1_50_0.tar.bz2
cd boost_1_50_0
./bootstrap.sh
echo "using gcc : 4.6 : i686-w64-mingw32-g++ : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar ;" > user-config.jam
./bjam toolset=gcc target-os=windows --address-model=32 variant=release threading=multi threadapi=win32 link=static runtime-link=static --prefix=/opt/boost_1_50_0-release-static-windows-32 --user-config=user-config.jam -j 10 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
In order to compile files in my project I use something like
i686-w64-mingw32-g++ -march=corei7 -mfpmath=sse -m32 -Wall -fmessage-length=0 -I"/opt/boost_1_50_0-release-static-windows-32/include" -std=c++0x -O3 -g0 -DNDEBUG -I"myProject/src/cpp" -c -o myProject/build/release/src/cpp/myproject.o myproject/src/cpp/myproject.cpp
The tests I have indicate that the regexps run fine but still I would like to resolve the warning.
EDIT
I found that additional options to the boost compiler can be added using a cxxflags= argument of bjam.
Example:
bjam cxxflags='-fPIC' ....
Maybe making sure to pass the same arguments as I do to the project could resolve the problem (particularly the arguments related to optimizations as suggested in the linked question).
Your compilers were compiled with different options :) Compiling the library on Linux and the program on Windows result in a situation where there is an identically named .data segment, but they aren't the same size. That could theoretically be interesting, inasmuch as a data segment is writable, but in practice, it shouldn't matter. Unless there is evidence to suggest this causes a problem of which I'm not aware, you can safely suppress that warning; I don't know how you'd make it go away, though.
I recently encountered this problem (i.e. linker warning "duplicate section has different size") when trying to compile boost for Windows using mingw.
The issue I had was that I compiled my application with -std=c++14 but when compiling boost I didn't specifically provide a dialect flag (which defaulted to -std=c++98 for g++ 5.3.0). Adding the dialect flag -std=c++14 when compiling boost solved the problem for me. See this answer for an explaination on how to set cxxflags when compiling boost.
I believe my solution might have worked for you (your application was compiled with -std=c++0x but boost was not provided any dialect flag). Although I am 6 years too late, I'll leave my answer here for others who happen to stumble-upon this issue.