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-08 13:38:38

On 9/8/2015 11:35 AM, Vladimir Prus wrote:
> On 08-Sep-15 6:32 PM, Edward Diener wrote:
>> On 9/8/2015 9:58 AM, Vladimir Prus wrote:
>>> On 08-Sep-15 4:27 PM, Edward Diener wrote:
>>>> On 9/8/2015 9:02 AM, Tom Kent wrote:
>>>>> On Fri, Sep 4, 2015 at 2:56 PM, Edward Diener
>>>>> <eldiener_at_[hidden]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>> What does your bjam user-config.jam file look like for this?
>>>>
>>>> I have separate user-config.jam files for each toolset, one of which
>>>> gets symbolically linked to user-config.jam
>>>> depending on which toolset I am using. This is necessary because Boost
>>>> build wants to invoke every toolset in
>>>> user-config.jam even when a b2 command line specifies only a single
>>>> toolset to use. I already complained about this on
>>>> the Boost build mailing list but evidently the change in Boost build
>>>> will not happen.
>>>
>>> I guess I don't understand why you find it that problematic? It's a very
>>> quick invocation of the compiler to detect
>>> some of its properties.
>>
>> It is problematical because it is impossible with mingw(-64)/gcc and
>> with clang to have more than one version working at
>> a time. I have already explained that mingw(-64)/gcc needs its own
>> compiler implementation found in the Windows PATH to
>> work properly. Similarly clang must have its target mingw(-64)/gcc in
>> the Windows PATH to work properly. It is
>> impossible to have more than one version of mingw(-64)/gcc coming
>> first in the Windows PATH.
>
> But we're not trying to compile anything. We're just asking for version
> and similar things? Or do we actually
> do anything that tries to run mingw linker?

You are invoking the compiler, and this causes problems with 
mingw(-64)/gcc and clang if the right DLLs are not in the PATH. The 
dependencies are run-time dependencies on DLLs so it does not matter if 
you are actually doing much of anything with the compiler.

I already had a long, frustrating discussion with the mingw-64 
developers about this and they are just adamant about the necessity that 
any given implementation's 'bin' directory must be in the PATH to just 
compile and/or link.