On 6/24/2015 8:02 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 23 June 2015 21:00 To: boost@lists.boost.org Subject: Re: [boost] Using Clang compiler in place of GCC

On 6/23/2015 7:41 AM, Paul A. Bristow wrote:

...

I have installed Clang 3.6.1 (along with previously used versions of GCC)

downloaded from LLVM and using the clang for LLVM Windows installer on Windows 8.1

I:\modular-boost\libs\fixed_point\example>clang++ --version clang version 3.6.1 (tags/RELEASE_361/final) Target: i686-pc-windows-gnu Thread model: posix

suggests that I have the compiler in place OK and it should be in my PATH (becos I asked for it to be).

--debug-configuration

notice: will use 'C:/LLVM/bin/clang++.exe' for clang-linux, condition <toolset>clang-linux-3.6.1

For a project, I have a jamfile starting

project : requirements <include>../include # quickdox/include <include>../../.. # modular-boost root #toolset requirements. # GCC requirements. #<toolset>gcc:<cxxflags>-std=gnu++11 # If requires C++11 library. <toolset>gcc:<cxxflags>-Wno-unused-local-typedefs <toolset>gcc:<cxxflags>-Wno-missing-braces # Clang requirements. #<toolset>clang:<cxxflags>-std=c++11 # If requires C++11 library.

(I also have environment BOOST_ROOT = I:\modular-boost)

when I run b2 toolset=gcc

all compiles and run as expected.

when I run b2 toolset=clang

I get messages like

common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang- linux-3.6.1 common.mkdir ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\clang- linux-3.6.1\debug

clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test\ clang-linux-3.6.1\debug\quick_auto_dox_index.obj quick_auto_dox_index.cpp:53:10: fatal error: 'iostream' file not found (or other files like cstddef, iomanip on other projects) #include <iostream> ^ 1 error generated.

"C:/LLVM/bin/clang++.exe" -c -x c++ -O0 -g -fno-inline -Wall -g -march=i686 -m32 -DBOOST_ALL_NO_L IB=1 -I"..\..\.." -I"..\include" -o "..\..\..\bin.v2\libs\quickdox\example\quick_auto_dox_index.test \clang-linux-3.6.1\debug\quick_auto_dox_index.obj" "quick_auto_dox_index.cpp"

(Full log attached).

This suggests that it is not finding the system file <iostream> ...

but I'm puzzled at what is missing (and why).

Suggestions most welcome.

Reiterating what Peter says you need a mingw distribution at c:\mingw or you need c:\mingw to be a symbolic directory link to your Mingw distribution. Not only that but the distribution needs to be mingw and not mingw-64. I have mentioned this dependence on only mingw (as oposed to the better mingw-64 ) on the clang developers mailing list and someone has replied telling me that they intend to work on compatibility with mingw-64, but you know how that goes...

Sigh :-(

...

I have found that the latest mingw distribution works with clang.

:-)

OK - I've installed c:/mingw and C:\MinGW\bin>mingw-get.exe install mingw32-gcc-g++

and I've got lots of .exe and .dll files at C:\MinGW\bin including a g++.exe and libstd++-6.dll

c:/program files/mingw-builds/x64-4.8.1-win32-seh-rev5/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8 .1/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible c:/program files/mingw-builds/x6 4-4.8.1-win32-seh-rev5/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/libstdc++.dll.a when searchin g for -lstdc++

And I've run Peter's suggested clang++ -v test.cpp with

I:\modular-boost\libs\quickdox\example>clang++ -v test.cpp

#include <iostream>

std::cout <<"hello world" << std:;endl;

and got the output clang_v_test.log

Obviously I am still missing something, but I'm still puzzled at what.

The 'x64' suggests you installed mingw-64 rather than mingw or else you have a mingw-64 installation in your PATH before the mingw installation. Make sure that c:\mingw\bin is at the beginning of your PATH when you compile/link with clang.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 24 June 2015 13:52 To: boost@lists.boost.org Subject: Re: [boost] Using Clang compiler in place of GCC

Paul A. Bristow wrote:

...

And I've run Peter's suggested clang++ -v test.cpp with ... and got the output clang_v_test.log

Obviously I am still missing something, but I'm still puzzled at what.

It now compiles, so <iostream> is fine, but tries to link using

"C:\\Program Files\\mingw-builds\\x64-4.8.1-win32-seh-rev5\\mingw64\\bin\\g++.exe" -v -m32 -o a.exe

which fails. You might try placing c:\mingw\bin in the PATH before the above one and see if it'll

link using

the g++ from there.

I do indeed intentionally have both mingw64 and now, reluctantly, mingw as well. So pushed c:/mingw/bin first and Bingo! Thanks to both for your invaluable help. (Sighs - Why does this have to be so unnecessarily difficult???) Paul

On 6/24/15 8:12 AM, Edward Diener wrote:

It is unnecessarily difficult because the clang developers, like the mingw-64 and mingw developers, cannot be convinced by intelligent programmers that hardcoded paths and the necessity of adding directories to the PATH variable, should not be a necessity for merely compiling/linking source code.

It is sometimes utterly wearying talking to these people, probably quite decent C++ programmers in their own right, and trying to convince them that their "Linux" toolsets on Windows need a better way to be used. They are just stuck in their own ways and usually refuse to budge.

At the same time, because mingw(-64)/gcc and clang are free tools and we are all appreciative of the ability to use them to test out Boost libraries, it is better to be civilized and a bit circumspect when trying to convince them of anything. Remember that these are normally first-rate compilers and their focus is on the compiler itself and not on the usability or documentation of their product.

LOL - I sense frustration here - and I'm totally sympathetic. I was thinking that it was just me becoming an "old person". So reading this makes me feel much better (unless you turn out to be an "old person" as well!). This is a problem of software developer's in general. They/We can't/won't step back and look at how something is actually going to be used. I believe that this is due to a number of factors. a) Coding the coolest, cleverest, most obscure, ideas is fun and lets us show of our otherwise unappreciated skills. The rest is not fun - it's just work. b) Stepping back to take an idea and make it into a real product that everyone can use is actually a separate job than doing a) above. That's why we have product managers and don't let software developers actually design products. The result might be very cool, but would only sell a couple of copies. Of course of free software that doesn't matter - so it's cool but sells zero copies. c) Many of these projects are very cool but have a short half life. How many fail to last or require too much maintenance. Most of them actually. d) I'm wondering if getting old enough to actually consider one's own mortality doesn't help make good software "product". I'm no longer interested in making something that's just cool and shows off my skills. I want make something that changes the world, hopefully beyond my life time. (I know this is a big dream - but what else can one do?). e) One thing that I think boost has been successful at is to provide a forum, facilities, and constructive feedback and criticism to those who feel some of this as I do. I think it has been somewhat successful in this endeavor. Software gets produced, it's documented, it's designed, it get's used, it has greatly affected the future development of C++ and I believe the development of software generally. It will have an effect beyond one's life time. This is what motivates me to spend time on bugging the bjam people, making the incubator work, trying to get more resources dedicated to library maintenance and all the other little projects and initiatives that I suck myself into. Although precious little progress has been made on these issues, even a little is an improvement. And there is always hope for the future. I realize that this totally off topic. (Hmm maybe it's not - given the quoted passage above). Sorry about that. I just wanted to get this off my chest. Robert Ramey

On 6/24/2015 11:39 AM, Robert Ramey wrote:

On 6/24/15 8:12 AM, Edward Diener wrote:

...

It is unnecessarily difficult because the clang developers, like the mingw-64 and mingw developers, cannot be convinced by intelligent programmers that hardcoded paths and the necessity of adding directories to the PATH variable, should not be a necessity for merely compiling/linking source code.

It is sometimes utterly wearying talking to these people, probably quite decent C++ programmers in their own right, and trying to convince them that their "Linux" toolsets on Windows need a better way to be used. They are just stuck in their own ways and usually refuse to budge.

At the same time, because mingw(-64)/gcc and clang are free tools and we are all appreciative of the ability to use them to test out Boost libraries, it is better to be civilized and a bit circumspect when trying to convince them of anything. Remember that these are normally first-rate compilers and their focus is on the compiler itself and not on the usability or documentation of their product.

LOL - I sense frustration here - and I'm totally sympathetic. I was thinking that it was just me becoming an "old person". So reading this makes me feel much better (unless you turn out to be an "old person" as well!).

The sense of frustration I voiced is because I can successfully argue about a better technical way to do things but the argument is not taken seriously if the current way of doing things is viewed as adequate for most end-users. The focus in clang and gcc is on the compiler and not on the end-user experience. Can I describe myself as being an "older person" without saying I am an "old person" <g> ?