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? - Likewise for clang? Also, what do we want to accomplish by using clang and mingw? Better error/warning reporting from clang? Something else?
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.
- 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?
- 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).
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.
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? - Volodya