[cfe-dev] libc++ in Windows

[James Gregurich]

Some Apple APIs have c++ code in them (webkit, webcore, javascriptcore). On 10.6, they would be linked against libstdc++ and you'd symbol clashes if you tried to use libc++ in a exe that linked against such libs.  I would expect at least some MS core libraries to have c++ code in them and be linked against their std lib also.


On Jun 29, 2013, at 7:06 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote:

> But Win32 doesn't use the standard library and it's no different than
> using STLPort or other STL implementation, and people have been doing
> that for ages. Provided that all third party libraries are also built
> with the same standard library implementation. I'm very curious where
> exactly you ran into problems?
> 
> On Sun, Jun 30, 2013 at 5:57 AM, James Gregurich <bayoubengal at mac.com> wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev