What do you need to install to use Clang on windows to build c++14 for 64 bit? - windows

UPDATE:
I've written a detailed tutorial that incorporates the top two answers on this question: http://blog.johannesmp.com/2015/09/01/installing-clang-on-windows-pt1/
TL;DR
On Windows, Given the following program:
#include <iostream>
int main()
{
int arr[] = {1, 2, 3, 4, 5};
for(auto el : arr)
{
std::cout << el << std::endl;
}
return 0;
}
I want to be able to do the following:
clang++ hello.cpp -o hello.exe -std=c++14
And get a 64 bit executable that just works. I don't want to have to append a ton of -I includes to tell clang where to find iostream or other standard c++ headers; I don't want to have to link in multiple steps.
I don't care so much about performance, efficiency, what linker is used, etc. I just want to be able to have clang/gcc/whatever set up correctly so that I can use a single, quick and dirty, console command like the one above.
What do I need to install for that to just work?
The Problem
As a predominately mac/linux user I'm used to being able to just use a package manager to install the latest version of clang, which just works.
I'm now trying to set up clang/gnu compiler on windows and it seems to be far more difficult, If only because there is little to no straightforward documentation out there (that I've been able to find)
I've tried to follow this tutorial: https://yongweiwu.wordpress.com/2014/12/24/installing-clang-3-5-for-windows - and was able to use it to get clang to build and link (using gcc 4.8.2), but the resulting binaries were 32 bit.
I've tried installing the latest prebuilt binaries of clang (3.6.2) and the 64 bit version of mingw-w64 (4.9.3 for 64 bit with posix and sjlj for exceptions), and am getting:
hello.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
Which seems to indicate that clang is not seeing gcc's files. It seems that some versions of LLVM/clang are looking for only certain versions of gcc, but that doesn't seem to be documented anywhere?
Similarly someone mentioned to me on the LLVM IRC that you need to modify clang's driver to look for gcc in certain paths?
What I'm looking for
I'm fine with building LLVM/Clang from source if necessary, but I'm really just looking for clear, step-by-step instructions that allow me to use clang++ as easily as I'm able to do with mac/linux
Something like:
Build this version of LLVM/Clang and place it in that directory
Download and install this version of cygwin (or mingw32 or mingw-w64) and install these packages.
etc..

Try installing MSYS2 and then installing the mingw-w64-x86_64-clang (binary) package:
pacman -S mingw-w64-x86_64-clang
It is a bit old at the moment (3.6.2), but it might be good enough for you. Then when you run the Win64 shell provided by MSYS2, clang will be on your path.
If it's not good enough, I have recently been building a 64-bit version of clang with MSYS2 and using it to compile native 64-bit Windows executables. My process was something like:
Use pacman to install base-devel, mingw-w64-x86_64-ninja, mingw-x86_64-cmake and perhaps some other packages that are needed by the build process.
Grab my PKGBUILD script for clang and the files in the same directory. This is based on the mingw-w64-clang-svn package from MSYS2, which is largely the work of Martell Malone. You can find him on the MSYS2 IRC channel and ask him more about it.
In a Win64, shell, go to the directory with my PKGDUILD, run export MINGW_INSTALLS=mingw64 (so you are only compiling the 64-bit version), and then run makepkg-mingw.
It is unlikely you will get everything right on the first try, and some files might need to be edited. Clang may have changed since the last time I did this and some patches might not apply cleanly.

if you use the upcoming clang 3.7.0, simply set PATH to include mingw-w64's bin, clang will work as you expect

You can install llvm pre-release binary for Windows here. MinGW-w64 can be downloaded here. Of course, you should make sure the paths are properly set up.
For the latest version of clang, e.g., clang 6.0.0. The above solution by #user5271266 will not be enough. Now the default target for clang Windows is x86_64-pc-windows-msvc (Assume that you are using 64 bit Windows).
In order to compile C++ source files, according to here, we should change the target:
clang++ -target x86_64-pc-windows-gnu -std=c++14 test.cc -o test.exe

Related

How to uninstall a compiler on mac?

First, I want to check all the c++ compilers I have installed on my mac.
I most probably have Clang and GCC both. So now I want to delete GCC.
please tell me how to do these 2 things.
You probably have clang pretending to be gcc (type gcc --version to check). But there's no clear definition of "installed" on Mac. You can place a compiler anywhere and run it from there (and I often have). But you can look in each part of your PATH (echo $PATH), and see what is in each directory. Or you can just use which clang and which gcc to see what would be picked up by default. You could even try locate gcc to find copies in some less usual locations that won't be run by default like versioned copies in homebrew (the first time you run this, it will tell you how to start the locate service).
But I expect that you really only have one compiler installed (clang). That's the normal situation. It just has hardlinks to gcc for backward compatibility.

Lift x64 Windows executable to LLVM bitcode and then compile back to x32 one?

So my idea is to "lift" 64-bits Windows executable to LLVM bitcode (or whatever is higher than assembly) and then compile it back to 32-bit executable.
I found that RetDec and McSema can lift PE binary to LLVM IR (and optionally C), but McSema requires IDA pro so I haven't tried it yet.
I have installed MSVC v143 and Windows SDK version 10.0.19041.0:
Clang version:
clang version 13.0.1 (https://github.com/llvm/llvm-project 75e33f71c2dae584b13a7d1186ae0a038ba98838)
Target: x86_64-pc-windows-msvc
Thread model: posix
So I compile this Hello World code in C using Clang:
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
then clang hello.c -o hello.exe
Check hello.exe file type with WSL:
$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows
You can download it here.
Then I use RetDec to lift it to LLVM IR:
python retdec-decompiler.py --no-memory-limit hello.exe
Output: here
After that we get:
Compile bitcode back to executable:
clang hello.exe.bc -m32 -v -Wl,/SUBSYSTEM:CONSOLE -Wl,/errorlimit:0 -fuse-ld=lld -o hello.x86.exe
Output: here
I guess functions like _WriteConsoleW are Win32 APIs, but ___decompiler_undefined_function_0 might be generated from the decompiler by some way.
Also, the decompiled code has no main function, but it had entry_point function. From hello.exe.ll:
hello.exe.c also has entry_point instead of main:
And also, hello.exe.c doesn't have ___decompiler_undefined_function_0
I also tried running the bitcode with lli:
lli --entry-function=entry_point hello.exe.bc
Output: here
Here is the link to the files.
How to make this compile? Thanks!
That's very ambitious.
I'm going to go out on a limb and say that every windows application includes thousands of system header files, most of which use types whose size differs between 32- and 64-bit systems and many of which contains #ifdef or other platform-dependent differences. You'll have a large .ll file full of windows64-specific types and code.
If the developers at Microsoft saw windows64 as a good chance to drop some hacks that were needed for w95 code, then you'll have w32-incompatible code there, too.
What you have to do is what the wine developers did — add code to cater to each problem in turn. There will be thousands of cases to handle. Some of it will be very difficult. When you see the number 128 in the .ll file, was it sizeof(this_w64_struct) in the original source, sizeof(that_other_struct) or something else entirely? Should you change the number, and if so, to what?
You should expect this project to take at least years, maybe a decade or more. Good luck.

Clang 3.4 does not look in correct places for the libstdc++ libraries

I am relatively new to Linux and Clang, and I am having trouble getting the Clang 3.4 toolchain to correctly determine where the libstdc++ libraries are. I am running Mint 17, have Clang-3.4 installed and have GCC 4.8 installed as well.
Using the verbose flag, the output looks like:
#include "..." search starts here:
#include <...> search starts here:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++
/usr/local/include
/usr/bin/../lib/clang/3.4/include
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
The search stops one subfolder shy of where it looks like all the libstdc++ headers live (in /c++/4.8). I have used the package manager to uninstall and reinstall gcc, clang, llvm and all dependencies. I have also tried reinstalling using the cli using apt-get.
A majority of the answers I've seen for this question revolve around changing the /FrontEnd/InitHeaderSearch.cpp file to look in the correct place for the libstdc++ stuff, but this doesn't exist on my machine. Rather, locate -b InitHeaderSearchdoes not find any results.
Aside from building clang and llvm from source, how else can I change where clang is looking for the libraries?
Thank you.

MinGW GCC -- Single 32-bit and 64-bit cross-compiler?

I've downloaded MinGW with mingw-get-inst, and now I've noticed that it cannot compile for x64.
So is there any 32-bit binary version of the MinGW compiler that can both compile for 32-bit Windows and also for 64-bit Windows?
I don't want a 64-bit version that can generate 32-bit code, since I want the compiler to also run on 32-bit Windows, and I'm only looking for precompiled binaries here, not source files, since I've spent countless hours compiling GCC and failing, and I've given up for a while. :(
AFAIK mingw targets either 32 bit windows or 64 bit windows, but not both, so you would need two installs. And the latter is still considered beta.
For you what you want is either mingw-w64-bin_i686-mingw or mingw-w64-bin_i686-cygwin if you want to compile for windows 64. For win32, just use what you get with mingw-get-inst.
See http://sourceforge.net/apps/trac/mingw-w64/wiki/download%20filename%20structure for an explanation of file names.
I realize this is an old question. However it's linked to the many times the question has been repeated.
I have found, after lots of research that, by now, years later, both compilers are commonly installed by default when installing mingw from your repository (i.e. synaptic).
You can check and verify by running Linux's locate command:
$ locate -r "mingw32.*[cg]++$"
On my Ubuntu (13.10) install I have by default the following compilers to choose from... found by issuing the locate command.
/usr/bin/amd64-mingw32msvc-c++
/usr/bin/amd64-mingw32msvc-g++
/usr/bin/i586-mingw32msvc-c++
/usr/bin/i586-mingw32msvc-g++
/usr/bin/i686-w64-mingw32-c++
/usr/bin/i686-w64-mingw32-g++
/usr/bin/x86_64-w64-mingw32-c++
/usr/bin/x86_64-w64-mingw32-g++
Finally, the least you'd have to do on many systems is run:
$ sudo apt-get install gcc-mingw32
I hope the many links to this page can spare a lot of programmers some search time.
for you situation, you can download multilib (include lib32 and lib64) version for Mingw64:
Multilib Toolchains(Targetting Win32 and Win64)
By default it is compiled for 64bit.You can add -m32 flag to compile for 32bit program.
But sadly,no gdb provided,you ought to add it manually.
Because according to mingw-64's todo list, gcc multilib version is done,but gdb
multilib version is still in progress,you could use it maybe in the future.
Support of multilib build in configure and in gcc. Parts are already present in gcc's 4.5 version by using target triplet -w64-mingw32.
gdb -- Native support is present, but some features like multi-arch support (debugging 32-bit and 64-bit by one gdb) are still missing features.
mingw-64-todo-list

g++ 4.4.x bug?

I have build a g++ v4.4 from source by using the archives provided by gcc.gnu.org.
But the resulting g++ cannot compile some of our projects c++ files. I am receiving a message simply saying: assembler error. It turned out that the assembler chokes on some extremely long symbol names, e.g. symbols names with a length of more then 2k.
Am I missing something to get it to work?
I would very appreciate an advice on how to get this working!
Environment: Debian-Lenny 64bit
EDIT: The mentioned c++ files are compiling fine with g++ versions v4.2 and v4.3. So I don't think it is a bug in the assembler (from binutils v2.18). Just to be sure I have also tried with binutils v2.20 - but I got the identical error message.
EDIT: I need g++ v4.4.x for the purpose of comparing the output of different g++ versions (and there is no g++ v4.4 in the official lenny repositories)
If your analysis is correct, it seems the proper course of action would be to file a bug for binutils. Or gcc, if it turns out the long symbol names are due to a bug in gcc's name mangling.
Of course, a (preferably reduced) testcase will help the developers fix your problem. Heck, it could have helped SO readers to verify your problems.
You're going to have to compile the corresponding gas instead of depending on what lenny has in his refrigerator (/usr/bin).
Why don't a) upgrade or b) use the backports archive or c) rebuild from current Debian sources on your box? I happily run testing with g++ 4.2, 4.3 and 4.4.
Worst case, you could install a new Debian release in a virtual environment such as a chroot, a Xen or Kvm instance, or inside VirtualBox.

Resources