[cfe-dev] libc++ in Windows

[James Gregurich]

I'm curious.  How are you going to set this up so that you can use libc++ on Windows for standard Win32 apps without clashing with Microsoft's c++ standard library at link time? I once made an effort to use libc++ on OSX 10.6 which is based on libstdc++. I could get a program to work, but once I tried to link with system APIs to actually build a real mac application, it would clash with libstdc++.

 

-James



On Jun 26, 2013, at 7:35 AM, Nico Rieck <nico.rieck at gmail.com> wrote:

> On 26.06.2013 02:57, Daniel Dilts wrote:
>> When I was looking at libc++ it didn’t appear to support Windows except maybe under MinGW.  What would be a good place to start to get libc++ to work on Windows?
> 
> I've been working on this on and off. Here's a braindump of what's needed:
> 
> 1. Port OS-specific things.
> 
>   This is rather small and I've done most of this already.
> 
> 2. C Standard Library.
> 
>   Microsoft's CRT is a royal PITA. It doesn't support a lot of things
>   required or expected, and other things have subtle differences.
>   Which is why I wrote a new standard library to make point 1 easier.
>   At first it was only a set of standard-compliant headers and
>   implementation stubs to get it to compile, but I've since
>   implemented certain parts. The hardest part for this route is, for
>   me at least, libm, and I don't know any modern BSD-licensed libm
>   that could be used.
>   The other way would be to further try and shoehorn MSVCRT and give
>   up C99- and full C++11-compatibility.
> 
> 3. Implement full dllimport/dllexport semantics so that libc++ can be
>   used as a DLL.
> 
>   Clang only support rudimentary dllimport/dllexport for functions.
>   Making it work with classes is a rather large non-trivial change.
>   I've been working on this and apart from vtable-handling and
>   cleanups it's mostly finished. Depending on that last point I may
>   put up some patches for review soon.
> 
>   This also requires changes to how libc++ applies those attributes.
>   Using them like ELF visibility doesn't work correctly for templates.
> 
> 4. Weak externals for PE to enable replacing operator new/delete.
> 
>   This was impossible with how dllimport was represented in LLVM
>   before. If my patches are excepted, it should be doable, but I
>   haven't looked into it again.
> 
> 5. Port an ABI library like libc++abi.
> 
>   I've ported some parts of libc++abi, but it's incomplete and
>   untested. It also needs an unwind library, which quickly leads
>   to the next point:
> 
> 6. Exception handling
> 
>   This is probably the biggest hurdle. There is some low-level support
>   for 64-bit SEH directives in LLVM already. 32-bit has the additional
>   Borland patent issue for SEH exception handling. The data structures
>   used by MSVC are also undocumented.
>   Implementing this for 64-bit by using the DWARF exception tables and
>   providing an appropriate personality routine is the easiest case,
>   and would also allow catching SEH exceptions from the OS.
>   Maybe it's also possible to implement such DWARF-based table-based
>   exception handling for 32-bit, without any way to catch SEH
>   exceptions.
> 
> 7. Some minor bugfixes I encountered along the way, like proper COMDAT
>   linkage for EH sections, proper varargs handling. I'll try to get
>   those committed soon.
> 
> 
> -Nico
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev