Hi, I have just finished my first GCC 4.6.2 (prerelease) personal build. I have a lot of exciting new things this time, so please, keep reading:
- GCC 4.6.1 has been released, so "gcc -v" now reports 4.6.2 (prerelease), hence the version bump in my packages - I have updated to the newest mingw-w64 crt and headers, and re-enabled wildcard globbing, so that you can call executables like this: "x86_64-w64-mingw32-strip *.exe" and have it strip all executables in the current directory. - There is an addon package containing the LLVM (Obj-)C(++) compiler, Clang. I submitted the necessary patches to get basic functionality like header searching etc. functional for mingw-w64. Details on the what and how below. - I have of course, updated all the packages to the latest (stable) versions: GCC: 4.6 release branch GDB: 7.3 release branch binutils: 2.21.52 (master?) branch mingw-w64: current trunk and all GCC prerequisites updated to latest versioned release. Now, the details on Clang: the project strives to be a very good C(++) compiler with very informative and helpful error messages, which is always a pro, especially when you remember GCC template errors are pretty unreadable. They also strive for GCC frontend compatibility, meaning that you *should* be able to replace "gcc"/"g++" with "clang"/"clang++" in all your build commands, and it should work. If you get an error complaining about an unimplemented feature, it's considered a bug in Clang. Clang is currently at version 2.9, and the svn trunk is versioned 3.0, hence that version is also on my package. I am able to update Clang seperate from the rest, so if there's a tentative fix for a problem, please ask me to update it, I will try to do so as soon as possible. The reason it is an addon package is that Clang still relies on gcc.exe to perform the link step. It does not have it's own object file linker (llvm-link and llvm-ld are something else entirely, see google for an explanation) and it can't run ld.exe on its own (which is hard to do correctly anyways, that's why you should always use gccc (or in this case) clang to link as well). To use clang, you could run make or configure with CC=clang CXX=clang++, which sets the commands up correctly. I have only tested small "Hello World" type programs, and they work, but nothing more. C++ is dependent on libstdc++, but not all c++0x features used in libstdc++ are available in Clang, so if you get C++ errors when using fancy c++0x features, check http://clang.llvm.org/cxx_status.html for what might be missing. Bugs can be reported at http://llvm.org/bugs/ and questions asked at [email protected]. Please be courteous when asking those nice people for help. I have done all I can to help you get the build process and setup out of the way, and clang should work out of the box. Keep in mind that Qt does not work with Clang on Windows, while it does on other platforms, I have reported some bugs around that issue. You're always welcome to remind the devs of course :) Links are below, in their usual places (and still uploading at the time of writing): http://sourceforge.net/projects/mingw-w64/files/Toolchain%20sources/Personal%20Builds/rubenvb/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/ http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/ Enjoy! Ruben ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
