Re: [boost] Compiling with Clang 3.7.0 from windows

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 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.