[cfe-dev] [LLVMdev] Windows strategy?

Mikael Lyngvig mikael at lyngvig.org
Mon Jun 11 12:12:24 PDT 2012

Hi Justin,

Thanks for your positive reply.  I imagined I'd be banned from the list or
something ;-)

I don't know if I'd call MinGW "unix-on-windows."  It's just a port of GCC
> with Windows headers/libraries.  You don't need to use bash or any other
> unix programs.

I'm thinking of the beast "ld" here.  As a former linker developer
(Link&Locate 386/XLINK386, an absolute/embedded linker from the 80ties and
90ties) and a long-time DOS/Windows user, I simply cannot get used to the
archaic notion that the order of the input libraries should matter the
least (as long as there are no duplicate symbols).  The DOS/Windows
platform gave up that notion some 20-25 years ago.  Yet, on most Unices,
people live with it every day and are accustomed to having to shuffle
libraries around every now and then to get the linker to link once again
(I've already done it two or three times with my tiny project - suddenly
out of the blue, it refuses to link and you have to shuffle a bit to get it
working again).

> MSVC ABI support in Clang is very incomplete as this point.  MinGW32
> support works fairly well, at least in my experience.  MinGW64 is a bit of
> a problem at the moment because of GCC versions.  Clang is hard-coded to
> search for headers in GCC version-specific locations.  For the dgn version
> of MinGW64, GCC 4.7.1 is used (in the latest release), but Clang only looks
> up for up to 4.7.0 at the moment.  That's why you're running into issues.
>  If I manually setup paths, I can build C++ programs using Clang using the
> MinGW64 headers/libraries:
> $ clang++ foo.cpp -o foo.exe -I "c:\mingw64\include\c++\4.7.1" -I
> "c:\mingw64\include\c++\4.7.1\x86_64-w64-mingw32" -I
> c:\mingw64\mingw\include

Oh, that's wonderful!  I am actually thinking of doing something about the
problem of the static library locations, somehow, once I get some time to
look at it.  Because there MUST be a better way than maintaining a static
list of library search directories.  Perhaps two external files containing
lists of directories to search (one for headers and one for libraries)?

Ohh, now I remember: I actually have the code below in my master
CMakeLists.txt file and yet the link fails:


So, I guess I've run into some kind of problem after all.  I'll try to file
a bug report on it.

>> As long as you do not violate any licenses, this should be fine.  I would
> love to see such a distribution!

Great, that's a deal then!  I'll check the GNU/MinGW licenses and see if it
isn't okay to do it.  Talk to the GNU guys, if need be.

> To be honest, I just haven't looked at it in detail yet.  I plan to, but
> most developers here are very busy and it takes time to get reviews.
>  Please bump the topic after a couple days of no replies.

Okay, I guess I also have to be a bit more patient and get to know the
process flow around here, before I jump to conclusions.  It contains a
deliberate provocation that's supposed to cause reactions (the part about
GDB being mostly for nostalgic people).

> File bugs for what doesn't work.

I'm still at the "is it me or is it the tool?" stage, so I am a bit
reluctant to file bugs.  But, hey, bug reports can be closed if incorrect.

> 5. Full support for libc++ on Win32/Win64.

Yup, that would be neat.

> And the vast majority of those Windows users will use MSVC instead of
> Clang.  Most will get by just fine with the Microsoft compiler, and they
> have no reason to really choose Clang, unless they want it for better ISO
> C++ compliance, or cross-compiling.

I think many more people are upset at Microsofts exorbitant prices than you
imagine.  After all, Visual Studio Professional is an expensive purchase
and Microsoft never really excelled at anything as far as I can tell.  I
think the popularity of MinGW, which is quite high I believe (over a
million downloads) speaks for itself.  The Express editions of VS are a
joke because they can't load most VS Pro solutions.

I doubt that's the general feeling...

Okay, I withdraw that thesis then.

>> Thank you for replying!

-- Love Thy Frog!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120611/d82601da/attachment.html>

More information about the cfe-dev mailing list