I want to install Clang compliler on my system. I went to this link, but so many download options out there confused me, as to which version should I download?
I'm using Dell's laptop : Windows 7 Basic 64-bit. I've already installed MinGW version 4.5.0. I've also installed Visual Studio 2008 as well as 2010.
What do you think is the best choice for me? Which Clang should I download? How should I configure it? I'm going to use Clang for the first time. So suggest me the best options!
By the way, can I configure Clang (or Visual Studio) so that Visual Studio may use Clang compiler to compile my C and C++ code?
EDIT:
What does it mean when the download page cryptically says "Front End Binaries for Mingw32/x86"?
You can use Clang with Visual Studio or MinGW. The choice is yours. But you'll need an external linker to produce Windows executables (MSVS's link.exe or MinGW's ld.exe/g++.exe).
If you want to use MinGW, download the next to last item (frontend binaries to mingw).
You can also compile Clang/LLVM from source, for that see here. This allows you to try out MSVS or MinGW(-w64). You'll need CMake for the build process.
UPDATE: regarding your edit: the "frontend" description reflects either the fact that llvm can be used as a backend in a GCC compilation through llvm-gcc (google has loads of info on this) or the fact that Clang itself is unable to link your code together into an executable or library. You still need the system's linker as I described above.
Clang now started releasing Windows snapshot builds
None. Front End Binaries # Mingw32/x86 is close, but you explicitly mentioned Windows 7 Basic 64-bit
so to be very specific you'll avail 64-bit benefits. So you'll follow steps at http://clang.llvm.org/get_started.html#buildWindows You may get VS2012 Express and the string with CMake should be "Visual Studio 11 Win64" Select Release instead of the default debug configuration from the dropdown and then build. Tool-chains are tightly coupled hierarchy, and MS's indulgence in non-standard extensions was never up-to-date by any other vendor implementation. Till llvm libcpp completes MinGW-W64 is the closest libstdc++ that I got from http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download Check for newer build at http://mingw-w64.sourceforge.net/ Following are my trial calls for Hi console app
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
The parameters are set on one single occasion of configuring IDE setting for say Code::Blocks The libs to pass to ld linker are determined using -v along-with g++ as clang++ will try to link libc++ sources against VS2012 binaries. Using g++ rather than ld is easier but seldom fails with ld not found internally owing to close coupling of tool-chain by hardcoding tool locations within source.
Related
I'm developing c++ code on Visual Studio 2019 (Version 16.5.4), and for the build i'm targeting Linux Ubuntu 18.04 with gcc 7.5 - both on a remote machine via ssh, and on my local machine via WSL2.
In both cases i have the same problem:
when using std::async, i have to add the compilation flag -lpthread to gcc's input, in order for the program to compile, otherwise i get
undefined reference to pthread_create
Moreover, the flag has to come after the cpp file name, i.e. g++ -lpthread xxx.cpp will fail with gcc 7.5, while g++ xxx.cpp -lpthread works fine.
so far so good, but here's the problem: i can't do a successful build through Visual Studio: when i add the -lpthread flag under Additional Options in the project's C/C++ properties, there doesn't seem to be any effect - the compilation still fails. moreover, since i don't see the flag being added to the full build command line (which is presented read-only), i have no way to see if the flag is actually being sent, and in the right order (namely after the cpp file name). since i don't see any way to manually edit the build command line, I'm out of ideas...
anyone?
Thanks.
I am trying to compile a 32-bit application on 64-bit Debian Stretch. I have compiled several other applications successfully this way, but one app that uses the pcap library is giving me problems. There does not seem to be a 32-bit version of this library anywhere for my platform.
Problem description
When I try to link my application, like this:
g++ (...objectfiles-and-options...) -m32 -o myapp -lpthread -lpcap
I get the error
/usr/bin/ld: cannot find -lpcap
I checked, and there is indeed no libpcap.so (or variant thereof) in /usr/lib32. However, all other libraries I am using is present there (like libpthread). I tried to create soft-links to the 64-bit pcap-libraries in there, just in case they should be multi-platform compatible, but that only resulted in "skipping incompatible /usr/lib32/libpcap.so when searching for -lpcap".
I've installed libpcap-dev, libc6-dev-i386, gcc-multilib and g++-multilib (obviously, since cross-compilation works fine for all applications that does not use libpcap). I would suspect there should be a libpcap-dev-i386 I could install, but there does not seem to be one.
Perhaps I should mention that the application compiles and links successfully as 64 bit.
Does anyone know what I am missing here?
You can compile libpcap yourself. It's probably the better solution than depending on packages.
Use configure for 32bit architecture and than give your compiler LDFLAGS pointing to your lib or install it in /usr/lib32/
(this question similar to this one but is not the same)
I'm using QtCreator on Windows platform, usually with vc toolchain.
sometimes with MinGW-W64, so for now, I'd like to try clang for some reasons.
unlike the post above - I don't use Qt library , just qtcreator as IDE, so I suppose I don't need to re-build it and QtCreator for a using clang kit, is it correct?
there are a few questions about that:
CLang distribution doesn't contain platform or even c/c++ runtime library, should i use it from vc kit? or/and MinGW runtime? how to switch between?
Correct my understanding please if it's wrong - for Win platform, clang has two options to use: 1) normal use - clang.exe ,as on any other platform 2) clang-cl.exe - additional layer which "looks like" cl.exe, and just parses cl command line keys and calls normal clang.
as I understand there is no LLDB for Windows platform , can I use GDB or CDB depends of the used runtime lib and binary format of the executable?
and finally - how to configure all this in qtcreator?
The following steps apply only to MSYS2 64-bit installation of QT Creator 4.5.1 (install instructions here), where you also have MinGW-w64 and mingw32-make installed on MSYS2; and you are building a non-QT C or C++ application.
These instructions use QMake, because QBS doesn't support MSYS2 clang. Well, QMake doesn't support it either, but I did figure out how to add support to QMake and I didn't figure out QBS.
There is QMake support for MSVC-clang but it outputs MSVC makefiles, so you can't build it with MSYS2 make. So that does not apply to us.
Install clang with pacman. I used pacman -Ss mingw-w64-x86_64-clang, your flavour may vary.
Add support for clang to QMake:
In the MSYS2 shell, go into /msys64/mingw64/share/qt5/mkspecs/
Do cp -a win32-g++ win32-clang-msys
Edit win32-clang-msys/qmake.conf and change gcc to clang, and g++ to clang++ (2 places each)
In the same file, take out -fno-keep-inline-dllexport -mthreads which are not supported by clang.
In QT Creator, set up a new Kit:
Go to Manage Kits.
Add a Custom Compiler for C and browse to the installed path (/mingw64/bin/clang.exe under your MSYS2 install).
Add a Custom Compiler for C++ as clang++.exe in the same place)
Add a manual Kit called Clang and set those two compilers as its compilers.
In the manual kit config set "Qt mkspec" as win32-clang-msys
Set "QT Version" to something. Even though I am using a non-QT project, the IDE doesn't like using the kit if "Qt version" is set to None.
Now you can attempt to build your project with the Clang kit and QMake.
I initially tried with QBS and the build failed due to this bug . But the build commands do succeed if I copy-paste them and cut out the bogus -target switch. So for QBS users I guess you have to switch to QMake in the meantime until they fix that bug.
Troubleshooting: I sometimes got an error Project ERROR: failed to parse default search paths from compiler output. This is a problem with QMake's lack of support for clang. The error tended to not occur if I built in a subdirectory of the .pro file, but did occur if I built in a sibling directory.
As a workaround: go back into win32-clang-msys/qmake.conf. Change the first clang back to g++. Then "Run Qmake" (from QT creator or commandline), then change it back. The first time you run QMake it writes the file .qmake.stash and then does not need to generate it again. The contents of this file were bogus for me but building seemed to work anyway.
Undefined references: I found that linking with -static produced a bunch of undefined references to __imp__cxa_ names. Not sure what the problem is here but maybe related to the bug with generating .qmake.stash. I guess the Qt developers would need to officially add non-MSVC Clang support to QMake.
Multiple definitions: The CLang linker gave multiple definitions for inline DLLexport functions. I found no workaround yet for this; g++ has -fno-keep-inline-dllexport to avoid this problem but CLang 5 does not support that flag.
The errors:
C:\VulkanSDK\1.0.17.0\Bin/vulkan-1.lib: error adding symbols: File in wrong format
or
C:\VulkanSDK\1.0.17.0\Bin32/vulkan-1.lib: error adding symbols: File in wrong format
I using Eclipse Version: Neon Release (4.6.0)
Build id: 20160613-1800
Compilers:
Cygwin 2.5.2(0.297/5/3)
MinGW-w64 gcc (x86_64-posix-seh, Built by MinGW-W64 project) 6.1.0
flags: -m64 or -m32
Can someone point me what I am doing wrong, or send me a example workspace with correct setup?
It is my first cross-platform project, so I probably doing something wrong.
I chose Eclipse from simple reason, it is almost same on Windows and Linux.
1) Update your SDK (latest ATMOW is 17)
2) That vulkan-1.lib in $VULKAN_SDK/Bin is MSVC++ library and there's no guarantee, it will work in gcc (doesn't for me - Cygwin is supposed to have some support, but it simply doesn't work for me).
Try to link directly to the vulkan-1.dll ( that is supply -L$WINDIR/System32 (x64 on x64 os) or -L$WINDIR/SysWOW64 (32 on 64) instead of the SDK paths ).
Otherwise you will need to build The Loader from source, which will be pain for Cygwin/MinGW (don't think there is official support yet). Or, you know, abandon Eclipse and join us on the dark side.
Edit/Update/Note: Just let clang use libstdc++. Has been working really well for me so far.
===============================
In the past I have been able to succeed by doing something with cmake, but just now I discovered a buildit script inside the lib directory of the http://llvm.org/svn/llvm-project/libcxx/trunk project tree.
This buildit script appears to not make use of libsupc++ which is what the cmake approach that I took earlier used. For instance, this guide shows one cmake incantation to produce a makefile for libc++, which will be able to take care of compiling and installation.
My question is what is the difference between these different ways to produce the LLVM-libc++ and which one should be used? Will they behave differently?
The buildit script does not appear to provide any help for installation. Are there directions anywhere for how to properly install the library? With my previous libc++ built with cmake, I had to always add -lc++ to the linker flags (and the path with -L), which is not necessary in my OS X makefiles.
The libc++ website has a nice overview of the possible ways to build libc++.
I suggest using CMake + libc++abi.
Also see the Arch Linux User Repository build script, which uses the buildit script. I installed libc++ from that and used it with the Arch Linux Clang package succesfully by using
clang++ -std=c++11 -stdlib=libc++ -lc++abi