On 03-Sep-15 7:02 PM, Paul A. Bristow wrote:

...

Can you get hello-world to compile by hand? Like:

"C:\Program Files\LLVM\bin\clang++.exe" -g -m64 hello.cpp

No

Oh!

But seeing this apparently self-contradicting message:

c:\mingw\bin\ld.exe: unrecognised emulation mode: i386pep Supported emulations: i386pe

I think I'd prefer not to use any version!

Edwards's response, along with some Googling, make the above make perfect sense, actually. i386pep (note 'p' at the end), is binutils name for 64-bit Windows. i386pe is 32-bit Windows. So the above message means that your mingw does not support 64-bit. (See http://comments.gmane.org/gmane.comp.gnu.binutils/39162) - Volodya

On 9/3/2015 3:19 PM, Ion Gaztañaga wrote:

El 03/09/2015 a las 18:02, Paul A. Bristow escribió:

...

...

? Which MinGW are you using?

Not the right one :-((

Which one do LLVM folks recommend to use?

I read something here:

http://clang.llvm.org/docs/UsersManual.html#mingw-w64

Actually I was able to use the latest clang built from source with mingw-64/gcc v5.1 32-bit and 64-bit. So the targeted mingw-64/gcc versions in the link above is a bit out of date. However for previous prebuilt versions, which understand only the mingw and not the mingw-64 directory structures, I could only use mingw/gcc 4.6.n or below for clang 3.4.1, and mingw/gcc 4.8.n or below for clang 3.5.2 and clang 3.6.2.

but hacks with newer versions here:

https://yongweiwu.wordpress.com/2014/12/24/installing-clang-3-5-for-windows/

Whenever you run clang, or mingw/gcc, you need to manipulate the PATH so that the correct version of mingw(-64)/gcc is at the beginning of the PATH for a given particular run. There is no way to set a permanent PATH so that running either clang or gcc will always work when you are using different versions of mingw(-64)/gcc and/or different versions of clang which target different versions of mingw(-64)/gcc. This is just a reality of mingw/gcc and clang on Windows. The above link not initially knowing this is what was at fault.

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

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.

...

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.

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

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

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.

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? What do you have in your batch file for setup? Thanks, Tom

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

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? - Volodya

On 9/09/2015 05:38, Edward Diener wrote:

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.

IIRC, their argument was that since the bin directory must be in the PATH to run the application (which is wrong, and bad practice for non-console apps at least) then they require it to be present when compiling so that running the app after compiling "just works". OTOH, enforcing that does make life easier for people who just want to compile and run unixy source packages rather than writing "real" Windows apps.

On 9/09/2015 13:26, Edward Diener wrote:

On 9/8/2015 7:56 PM, Gavin Lambert wrote:

...

On 9/09/2015 05:38, Edward Diener wrote:

...

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.

IIRC, their argument was that since the bin directory must be in the PATH to run the application (which is wrong, and bad practice for non-console apps at least) then they require it to be present when compiling so that running the app after compiling "just works".

'Compile/link' and 'run' are two separate steps. Doing the first does not always mean doing the second. A number of Boost tests are just compiles. An end-user should be allowed to configure a 'run' as he desires. Creating pre-conceived assumptions about how software should be used which limit the freedom and flexibility of programming is almost always a sign of bad programming design.

I completely agree. I was just filling in some context.

On 9/8/2015 9:13 PM, Tom Kent wrote:

On Tue, Sep 8, 2015 at 8:27 AM, 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.

...

What do you have in your batch file for setup?

The batch file sets the PATH and the user-config.jam for whichever toolset is being invoked. Then b2 is invoked with a particular toolset.

This setup is the only way I can work with multiple versions of mingw(-64)/gcc and multiple versions of clang.

Do you think you could post the contents of these files? I'd really like to see what you did to setup the toolsets in the (various) user-config.jam files. The batch file sounds more self explanatory, but would still be nice to see.

Here is a user-config.jam for any VC++ version:

# Configure specific gcc version, giving alternative name to use. # using gcc : 3.3 : C:/Utilities/MinGW/v3.3.3/bin/g++ ; # using gcc : 3.4 : C:/Utilities/MinGW/v3.4.5/bin/g++ ; # using gcc : 4.3 : C:/Utilities/MinGW/v4.3.0/bin/g++ ; # using gcc : 4.4 : C:/Utilities/MinGW/v4.4.0/bin/g++ ; # using gcc : 4.5 : C:/Utilities/MinGW/v4.5.2-1/bin/g++ ; # using gcc : 4.6 : C:/Utilities/MinGW/v4.6.2-1/bin/g++ ; # using gcc : 4.7 : C:/Utilities/MinGW/v4.7.2-1/bin/g++ ; # using gcc : 4.8 : C:/Utilities/mingw-w64/i686-4.8.5-posix-dwarf-rt_v4-rev0/mingw32/bin/g++ : <cxxflags>-ftrack-macro-expansion=0 ; # using gcc : 4.8x64 : C:/Utilities/mingw-w64/x86_64-4.8.5-posix-seh-rt_v4-rev0/mingw64/bin/g++ : <cxxflags>-ftrack-macro-expansion=0 ; # using gcc : 4.9 : C:/Utilities/mingw-w64/i686-4.9.3-posix-dwarf-rt_v4-rev0/mingw32/bin/g++ : <cxxflags>-ftrack-macro-expansion=0 ; # using gcc : 4.9x64 : C:/Utilities/mingw-w64/x86_64-4.9.3-posix-seh-rt_v4-rev0/mingw64/bin/g++ : <cxxflags>-ftrack-macro-expansion=0 ; # using gcc : 5.1 : C:/Utilities/mingw-w64/i686-5.1.0-posix-dwarf-rt_v4-rev0/mingw32/bin/g++ : <cxxflags>-Wno-unused-local-typedefs <cxxflags>-ftrack-macro-expansion=0 ; # using gcc : 5.1x64 : C:/Utilities/mingw-w64/x86_64-5.1.0-posix-seh-rt_v4-rev0/mingw64/bin/g++ : <cxxflags>-Wno-unused-local-typedefs <cxxflags>-ftrack-macro-expansion=0 ;

# ------------------- # MSVC configuration. # -------------------

# Configure msvc (default version, searched for in standard locations and PATH). using msvc ;

using xsltproc ; using boostbook : "C:/Utilities/Docbook/xsl" : "C:/Utilities/Docbook/xml" ; using doxygen ; using fop : "C:/Utilities/RenderX/XEP/xep.bat" : "C:/Program Files (x86)/Java/jre7" ; using quickbook ; using auto-index : C:/Programming/VersionControl/modular-boost/tools/auto_index/build/auto_index.exe ;

using python : 2.7 : C:/Utilities/Python278_32 ;

# using clang : 3.4 : C:/Utilities/LLVM/341/bin/clang++ # : # <warnings>on # ; # using clang : 3.5 : C:/Utilities/LLVM/352/bin/clang++ # : # <warnings>on # <cxxflags>-Wno-dll-attribute-on-redeclaration # ; # using clang : 3.6 : C:/Utilities/LLVM/362/bin/clang++ # : # <warnings>on # <cxxflags>-Wno-unused-local-typedef # <cxxflags>-Wno-dll-attribute-on-redeclaration # ; # using clang : 3.8 : C:/Programming/VersionControl/bninja_installed_clang/bin/clang++ # : # <warnings>on # <cxxflags>-D__MINGW_FORCE_SYS_INTRINS # <cxxflags>-Wno-unused-local-typedef # <cxxflags>-Wno-dll-attribute-on-redeclaration # ;

All other user-config.jam files are just variations of the above with the appropriate line uncommented for whatever toolset I am using. They each have a name such as user-config.gcc-5.1 etc. In my batch file, which is invoked with a toolset name ( among other things ), I do two things: 1) Erase the current user-config.jam, which is just a symbolic line, if it exists, and create a symbolic link of user-config.jam to the appropriate toolset version I want to use. 2) Set the Windows PATH according to the appropriate toolset I want to use ( VC++ is ignored since Boost build takes care of that ). Then b2 is invoked accordingly. It has the correct user-config.jam and the correct Windows PATH for the toolset. I tried other schemes in the past but always ran into problems with multiple toolsets of gcc and clang on Windows because of Boost build's invocation of any toolset it sees in user-config.jam. By manipulating user-config.jam so that only one compiler toolset exists when Boost build sees it I was able to workaround such problems.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 03 September 2015 16:23 To: boost@lists.boost.org Subject: Re: [boost] Compiling with Clang 3.7.0 from windows

On 9/3/2015 10:02 AM, Paul A. Bristow wrote:

...

I've downloaded the shiny new Clang 3.7 and added this to my user-config

This is my experience with clang built from source:

If you are running clang as a 64-bit compiler you need to "use" a 64-bit version of mingw-64, and not mingw which is only 32-bits. By "use" I mean one of two things. Either the 'bin' directory of the 64-bit version should be prepended to your Windows PATH when invoking clang++ or you use the '-- sysroot=some_mingw' option on the command line when invoking clang++, where 'some_mingw' is the path to the 64-bit mingw implementation. I have not used the second method but have been told it should work.

What I do, in a batch file before invoking clang++, is to prepend to the Windows PATH the clang++ bin directory followed by the bin directory of the mingw-64 implementation I want clang to use. Then when clang++ is invoked it finds everything properly. If you are compiling clang++ for 32-bit code you need to "use" a 32-bit version of mingw(-64)/gcc and if you are compiling clang++ for 64-bit code you need to "use" a 64-bit version of mingw-64/gcc.

As far as pre-built versions of clang I have used clang 3.6.2, 3.5.2, and clang 3.4.1. None of these versions could "use" mingw-64 but only mingw. This means that none of these versions could be used to compile 64-bit code since mingw only supports 32-bit code. I have not tried the new pre-build clang 3.7 yet, which supposedly is capable of using mingw-64 ( I know the latest clang built from source can "use" mingw-64 but I am not sure if this capability got into the 3.7 release ).

I'm a bit wary of working on a solution that requires a bat file to manipulate the PATH. (It is also potentially inconvenient because it complicates other b2 code?) Surely Boost.Build user-config.jam should be able to do this? If only we knew what Clang needs? I've downloaded from mingw64 C:\Program Files\mingw-w64\x86_64-5.1.0-win32-seh-rt_v4-rev0\mingw64\bin (Assuming that for Windows the SEH option is best? - but user-config.jam should also cater for Linux hosts? So there should be different setups for Windows?) I've also got this C:\MinGW\mingw32\bin But I'm not sure if I need this at all. I'm completely confused about exactly what the Clang compiler is using mingw for. Is it the loader ld.exe? Is it libstdc++? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On 04-Sep-15 11:22 PM, Edward Diener wrote:

...

I'm completely confused about exactly what the Clang compiler is using mingw for.

It uses he mingw/gcc header files, static libs, import libs and DLLs. Essentially it is using the mingw/gcc RTL, which includes support for the C++ standard library and the Windows API.

Paul's error message means clang also uses mingw linker, ld.exe. Last time I've heard, half-a-year ago, LLVM folks were working on their own linker, but it barely reached 'links hello-world' stage. So using mingw linker is not unexpected. - Volodya