On 9/6/2015 1:53 PM, Vladimir Prus wrote:
On 04-Sep-15 10:56 PM, Edward Diener wrote:
On 9/4/2015 2:38 AM, Vladimir Prus wrote:
On 04-Sep-15 1:32 AM, Edward Diener wrote:
It would be nice if we could discover some easy steps to run the official clang 3.7 binary on an official "mingw-build" or "mingw-w64" build and configure user-config.jam correctly.
It needs far more Boost build/bjam expertise for the clang-linux.jam than I am able to provide. I know what would need to be done but I have no idea how to do it within Boost build.
Could you start by documenting, say on Trac or GitHub Wiki, what needs to be done? As it stands, I'm not even clear which of zillion mingw flavours to install.
I can not document on Github Wiki, trac, and on this mailing list what needs to be done. I will gladly discuss what I know here.
Okay. Can we start with simple:
- What URL to a mingw distribution you was testing with?
I have a number of mingw distros with which I can test. If you want to test with mingw-64/gcc just download the mingw-64 installer from https://sourceforge.net/projects/mingw-w64/files/latest/download. Executing the installer will allow you to install a number of 32-bit and 64-bit ( on 64-bit OSs ) versions of mingw-64 to your directory of choice. It is by far the easiest way to get mingw-64 distros installed. Prior to mingw-64 I would get the latest mingw from their sourceforge site at https://sourceforge.net/projects/mingw/files/. I would manually get what I needed for a particular version of mingw/gcc and put it all together into a directory for a particular version of mingw/gcc. Currently they have an installer to do this for you but it only gets the latest version of mingw/gcc that they have to offer. Given that this is gcc-4.8.1-4 and that mingw-64 is just better supported in every respect I would ignore mingw in favor of mingw-64 unless you really wanted to test an older version of mingw/gcc such as 4.7.n on down and were willing to manually install everything for that older version as I have done.
- Likewise for clang?
Prebuilt versions of clang for Windows can be downloaded from the llvm page at http://llvm.org/releases/download.html. You can see Windows versions for clang 3.4 through 3.7 there. I usually only test the latest 3.n.release version, so for clang 3.6 I only bother to test the 3.6.2 version. Versions 3.4 through 3.6 on Windows should only be used to compile 32-bit code since it can only use mingw and not mingw-64 as its Windows gcc implementation. The prebuilt version 3.7, which I have not tried yet since it is fairly new, can evidently compile both 32-bit code and 64-bit code, but I would use the 32-bit version to compile 32-bit code and the 64-bit version to compile 64-bit code. The reason for this is that I have my doubts that the 32-bit version can compile/link with a mingw-64/gcc 64-bit implementation because the default exception model for the mingw-64/gcc 64-bit implementation is 'seh'. Similarly I have my doubts that the 64-bit version can compile/link with a mingw(-64)/gcc 32-bit implementation because the default exception model for the mingw(-64)/gcc 32-bit implementation is 'dwarf'. Whereas the respective 32-bit and 64-bit versions of clang-37 are probably built with the correct statically linked exception handling mingw(-64)/gcc libraries for their respective bits. You can also build clang from the latest source, where the latest source version is clang 3.8. You can follow the instructions for getting the latest clang at http://clang.llvm.org/get_started.html. There are no instructions for building clang on Windows except for the Visual C++ targeted version. I offered to add instructions on that page for the mingw(-64)/gcc targeted version on the clang developer's mailing list but my offer was ignored. If you are interested I can give it here. Just ask.
Also, what do we want to accomplish by using clang and mingw? Better error/warning reporting from clang? Something else?
1) It adds two more compilers to test Boost on Windows, other that just VC++. 2) Both gcc and clang are better C++ standard conforming compilers than VC++ has been. I trust what they find as C++ standard conformance errors more than I trust VC++. 3) The VC++ preprocessor remains "broken" still with VC++ 14 ( VS2015 ). It's impossible to write/test macro code, as I have done with VMD and Boost PP, without being able to check highly conformant preprocessor such as gcc and clang. Of course Boost Wave is also an enormous help. 4) I think VC++ has done an admirable job reporting complicated template misuse errors in its output, but both gcc and even more so clang are also first-rate in reporting such others. You can never have "enough" different ways at looking at template errors to discover what may be wrong in your template code. Of course there are many people who will just say to use Linux if you want to test gcc and/or clang and I understand that. Even though I have fun multi-booting into various Linux distros I am still much more comfortable using Windows.
Essentially for any given clang release the Boost build toolset for clang on Windows ( remember that clang-linux.jam supports both clang on Linux and clang on Windows targeting gcc ) needs both the directory where the clang version resides and the directory where the target mingw(-64)/gcc version resides. These directories needed to be prepended to the Windows PATH for all Boost build actions such as compile/link/run etc.
- Why do you need clang in PATH? Is the compiler not able to find other component relative to itself?
It is possible that clang does not need to be on the PATH, but I always add it to the beginning of the PATH anyway. I do know absolutely that when you attempt to use mingw(-64)/gcc directly that it's 'bin' directory must be on the PATH for gcc to even compile/link correctly. If clang can work without it's 'bin' directory being on the PATH that is great, but I take the conservative, safe way.
Sounds unfortunate, but we're not in position to fix mingw.
Exactly.
- If clang needs mingw, it seems reasonable to document that mingw must be in PATH, and that the user must add such settings on Windows?
Is that a question or an assertion ?
As I mentioned in a previous post the --sysroot option may be a way for using a particular mingw(-64) distribution, without needing that distribution to be on the PATH, but I have never tried it. It was mentioned to me by someone on the clang developer's mailing list. As usual, in regard to clang, it is barely documented.
Was that option supposed to be passed to clang?
It can be passed to clang, evidently. Try finding any real clang documentation about it or its use <g>. It exists originally for gcc so the clang answer is inevitably to read the gcc docs and it should work the same.
- If one has mingw with both 32 and 64 bit support, can one use it with clang, with -m32 and -m64 options both working? (If not, that seems like a huge bug in clang)
Mingw only has 32-bit support so I assume you mean mingw-64. The mingw-64 distributions offer separate distributions for 32-bit and 64-bit builds. So for any gcc release you are installing 32-bit and 64-bit distributions in separate directory trees.
That's unfortunate too, given that gcc has a way to build multiple variants, install them alongside, and pick the right one depending on -m32/-m64 options (or any other options).
I assume you mean gcc on Linux. I know very little of how to install build/install multiple versions of gcc on Linux. Some of the Linux distros to which I can multi-boot have the ability to install more than one version of gcc but I notice that the executables are then changed to incorporate the version number in them except for the default distro gcc version, which is just called 'gcc' etc.
Clang can work with either 32-bit or 64-bit code using -m32 and -m64 respectively, but it needs to "use" a 32-bit or 64-bit mingw-64/gcc release accordingly.
The upshot of all this is that it may be possible to compile/link with clang and a target mingw(-64)/gcc without any PATH manipulation at all ( using --sysroot ). But unless one is creating a module with complete static linking there will be dependencies on mingw(-64)/gcc DLLs when running,
I'd presume the right solution would be for mingw to install their runtime as SxS assemblies, so that they can be easily found at runtime, but cleary that's not happening any time soon.
Ho ho ho ! Try telling that to the mingw and mingw-64 developers on their respective mailing lists, and see what response you get. I could not even convince the mingw-64 developers that a distribution setup that does not allow you to compile/link, without having its 'bin' directory in the Windows PATH, was wrongly designed.
So my own preferrred solution very conservatively puts the clang clang 'bin' first in the PATH followed by the mingw(-64)/gcc 'bin' next in the PATH, before invoking any Boost build functionality.
I see. Could you give me the URLs of downloads to try, so that I can look for possible workarounds?
I give the mingw and clang URLs above.