<div class="gmail_quote">2011/9/25 Ruben Van Boxem <span dir="ltr"><<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">2011/9/25 Ruben Van Boxem <span dir="ltr"><<a href="mailto:vanboxem.ruben@gmail.com" target="_blank">vanboxem.ruben@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="gmail_quote"><div>2011/9/23 Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com" target="_blank">hhinnant@apple.com</a>></span><br></div><div><div></div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On Sep 23, 2011, at 3:14 PM, Ruben Van Boxem wrote:<br>
<br>
> Can anything be done about this GCC incompatibility: <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980#c7" target="_blank">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980#c7</a> ? 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.<br>



<br>
</div>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.<br></blockquote><br></div></div>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.<br>


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


I envision a full LLVM alternative to libgcc and libsupc++, but that is still a looooong way off.<br><br>Comments and especially commits are very welcome!<br></div></blockquote></div></div><div><br>Apologies, I missed a return statement in the previous patch. Attached is an updated one.<br>

<br></div><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class="gmail_quote"><font color="#888888"><br>Ruben<br></font><br>
PS: the only thing holding back a test run is an undefined reference in mingw-w64's winpthreads library.<br></div></blockquote></div></div></blockquote><div><br>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.<br>
<br>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:<br>#if defined _LIBCPP_DLL<br>
#ifdef _BUILDING_LIBCPP<br>#define _LIBCPP_API __declspec(dllexport)<br>#else<br>#define _LIBCPP_API __declspec(dllimport)<br>#endif<br>#else<br>#define _LIBCPP_API<br>#endif<br><br>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++.<br>
<br>Ruben<br></div></div><br>