Re: [boost] Compiling with Clang 3.7.0 from windows

Subject: Re: [boost] Compiling with Clang 3.7.0 from windows
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-09-06 17:46:29

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.