[cfe-dev] [PATCH] Libc++ Windows fixes

[Ruben Van Boxem]

2011/9/25 Ruben Van Boxem <vanboxem.ruben at gmail.com>

> 2011/9/25 Ruben Van Boxem <vanboxem.ruben at gmail.com>
>
>> 2011/9/23 Howard Hinnant <hhinnant at apple.com>
>>
>>> On Sep 23, 2011, at 3:14 PM, Ruben Van Boxem wrote:
>>>
>>> > Can anything be done about this GCC incompatibility:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980#c7 ? It is preventing
>>> me from linking a functional libc++ (as Clang is not capable of producing
>>> correct object files to be linked together), and of course, testing the
>>> beast :). To fix it, this basically needs the functions in question to not
>>> be declared as "always inline", because GCC produces an error in this case.
>>> If Clang does not inline in this case, it should really also produce an
>>> error instead of silently ignoring the attribute.
>>>
>>> Seems like the easiest thing to do would be to rewrite these without
>>> using va_list.  Only one or two arguments need to be supported.  Just make
>>> these always-inline templates.
>>>
>>
>> Thanks for the valuable idea. Attached patch implements these for
>> non-clang compiles (#ifdef __clang__). I also used the available *_l
>> function variants for those that are available on Windows (MSVC++ runtime
>> 8.0 and later). I also fixed up the win32 support header stuff to work with
>> the full <locale> header things required.
>> I added a mingw bit to the lib/buildit script, that for now quite
>> hackishly links to libsupc++ and allows multiple definitions due to a
>> missing alternative. This will at least allow some testing to happen on the
>> rest of the libc++ code, that isn't compiled into the library itself.
>> I envision a full LLVM alternative to libgcc and libsupc++, but that is
>> still a looooong way off.
>>
>> Comments and especially commits are very welcome!
>>
>
> Apologies, I missed a return statement in the previous patch. Attached is
> an updated one.
>
>
>> Ruben
>>
>> PS: the only thing holding back a test run is an undefined reference in
>> mingw-w64's winpthreads library.
>>
>
Since this undefined reference was due to a missing extern "C" in
winpthreads, nothing is stopping me and anyone alse from running the test
suite for Windows! Except for a small attached patch, that also allows GCC
to be used (with appropriate environment variables), because GCC on Windows
does not produce a.out, but a.exe (Clang always uses a.out) as a default
executable name. Feel free to change the "a.out" name to "test" or something
else for every other platform.

There is still an unanswered (by Howard or anyone else that feels like he
can make high-impact decisions): How will the Windows DLL exports be marked
in libc++? The simplest would be something like this:
#if defined _LIBCPP_DLL
#ifdef _BUILDING_LIBCPP
#define _LIBCPP_API __declspec(dllexport)
#else
#define _LIBCPP_API __declspec(dllimport)
#endif
#else
#define _LIBCPP_API
#endif

and *every* symbol/class marked with these macros. The problem with this is
that _LIBCPP_DLL needs to be defined when linking user programs to libc++.
The alternative is creating/maintaining a .def file listing all the exports.
This also allows for better ABI backwards-compatibility and is done by
libstdc++. The problem with this approach is 1) getting a list of all these
symbols, 2) maintaining this list when ABI changes, and 3) MSVC and
MinGW/GCC/Clang mangle C++ in different ways. A third and the least refined
way is using --export-all-symbols when linking the libc++ DLL. I do not know
if this works though (testing it now). All this nonsense has also been
resolved recently in LLVM/Clang, and perhaps libc++ can copy their approach,
if such a user-library approach makes sense for a runtime library like
libc++.

Ruben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110925/92920ca8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testitwindows.patch
Type: application/octet-stream
Size: 765 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110925/92920ca8/attachment.obj>