<div class="gmail_quote">2011/9/23 Howard Hinnant <span dir="ltr"><<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Committed revision 140384.<br>
<br>
Howard<br></blockquote><div><br>Thanks.<br><br>Can anything be done about this GCC incompatibility: <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10980#c7">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>Ruben<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On Sep 23, 2011, at 9:22 AM, Ruben Van Boxem wrote:<br>
<br>
> 2011/9/23 Ruben Van Boxem <<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>><br>
> 2011/9/22 Ruben Van Boxem <<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>><br>
> 2011/9/22 Ruben Van Boxem <<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>><br>
> 2011/9/22 Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>><br>
> On Thu, Sep 22, 2011 at 12:35 PM, Ruben Van Boxem<br>
> <<a href="mailto:vanboxem.ruben@gmail.com">vanboxem.ruben@gmail.com</a>> wrote:<br>
> > 2011/9/22 Howard Hinnant <<a href="mailto:hhinnant@apple.com">hhinnant@apple.com</a>><br>
> >><br>
> >> Patch committed revision 140328.<br>
> ><br>
> > Thanks!<br>
> ><br>
> > Now that I've got your attention, on to more... involved... matters :-)<br>
> ><br>
> > In order to support libc++'s current implementation using<br>
> > cat[gets|open|close] and nl_types.h (which I ignored for now), I would need<br>
> > to pull in some external code, namely mingw's libcatgets and a supporting<br>
> > iconv library. These can all go under support/win32 and leave all other<br>
> > platforms unchanged of course, and leave the rest of libc++ as coherent as<br>
> > possible on all platforms. I understand Howard has an acceptable aversion to<br>
> > including too much foreign code in libc++, and hope you can see the need for<br>
> > this here.<br>
> ><br>
> > There are some issues though:<br>
> > - libcatgets is licensed under GPLv2. If I can go through with this, I can<br>
> > ask/plead/beg the original author to allow a license change or ask him to<br>
> > make an exception for libc++. I know of no existing alternative.<br>
> > - for the iconv part, GNU libiconv is of course out of the question. There<br>
> > are two projects of interest: APR-iconv (Apache License 2.0) and win-iconv<br>
> > (BSD 2-clause license), the latter being tiny but primitive. The first is a<br>
> > truly first class implementation as far as I can see, and with minor<br>
> > refactoring could be included in the libc++ Windows build.<br>
> > - I am not an Open Source license lawyer, and do not know what would be<br>
> > acceptable for libc++ in this regard.<br>
> ><br>
> > I want to ask what's "best", before starting with the implementation. The<br>
> > only real alternative is writing all this (ie catgets with supporting iconv<br>
> > code) from scratch, which I don't see myself doing in the near to distant<br>
> > future. Another way is to completely replace libc++ parts that use/rely on<br>
> > these API's, but this would make libc++ a lot more assymetric across<br>
> > platforms. In theory, these support files could help other platforms where<br>
> > these API's are missing.<br>
> ><br>
> > Please let me know what you think. Thanks!<br>
><br>
> MSVC doesn't provide a non-trivial implementation of<br>
> std::messages::do_open etc., so I don't see why it matters if libc++<br>
> does not provide one on Windows.<br>
><br>
> Hmm, glancing through libstdc++'s headers, it doesn't seem to do much more :(. Then the question becomes (if the authors/copyright holders of the support code in question do not want to have it used in win32 libc++), should I just mimic current behavior of the other "Big 2" (MSVC/GCC) in this regard? What would I be missing out on then? Is it really only n3290's 22.4.7?<br>
><br>
> Implementing stubs was easy, so I just went ahead with it. I can always improve on it later if I want. Attached is another incremental patch.<br>
><br>
> Notes:<br>
> - inclue/__bit_reference: Win32 <yvals.h> has a line: "#define _C2 1" which obviously messes up the templates in this file. I added n extra underscore to work around this, and did the same to _C1 for consistency.<br>
> - include/locale: include my support header for vasprintf, make the std::message functions stubs for Windows, mirroring other C++ Standard Library implementations on Windows.<br>
> - include/support/win32/support.h: add two missing functions and implement them naively in function of not-missing functions.<br>
> - src/locale.cpp: exclude langinfo.h inclusion for Windows. More work is needed here later to provide an alternative.<br>
> - src/support/win32/suppport.cpp: implementation.<br>
><br>
> Please comment on this if something looks weird or wrong.<br>
><br>
> Clang failed me (<a href="http://llvm.org/bugs/show_bug.cgi?id=10989" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=10989</a>) so, I'll need to resort to GCC and its unhelpful error messages in the meantime.<br>
><br>
> Ruben<br>
><br>
> This time with patch. Note that the 32% is a rough estimate, mostly meant for my own encouragement.<br>
><br>
> PS: thanks for the quick patching for the assembler error.<br>
><br>
> I have reached 100%, that is, linking Clang object files fails horribly, and GCC can't inline var_args functions, but every source file builds with GCC and Clang apart from these non-libc++ related issues.<br>
><br>
> The patch explained:<br>
> - include/__bit_reference: Win32 <yvals.h> has a line: "#define _C2 1" which obviously messes up the templates in this file. I added an extra underscore to work around this, and did the same to _C1 for consistency.<br>
> - include/locale: include my support header for vasprintf, make the std::message functions stubs for Windows, mirroring other C++ Standard Library implementations on Windows.<br>
> - include/support/win32/support.h: add two missing functions, and define a swprintf for MINGX32. Technically, VS2003 also has a bad declaration, but as it doesn't support a lot more that isn't really relevant for libc++.<br>
> - include/suppport/win32/locale.h:<br>
> - add missing defines for prefixed versions of functions.<br>
> - Redo newlocale to accept a third parameter. Functionality should be ok, as the third parameter is always 0 in libc++.<br>
> - Implement is(w)blank naively, which are missing from msvcrt.<br>
> - define LC_ALL_MASK<br>
> - remove the nl_types enum definition, as it is now unused.<br>
> - src/locale.cpp: exclude langinfo.h inclusion for Windows, instead including <locale.h>. msvcrt does not provide a C99 compliant lconv implementation, so for Windows, some int_* prefixed struct members are not present. I used the non-prefixed ones instead. Technically incorrect, but should work OK in most cases.<br>
> - src/string.cpp: include Win32 support header.<br>
> - src/thread.cpp: omit inclusion of sys/sysctl.h on Windows.<br>
> - src/support/win32/suppport.cpp:<br>
> - fix vasprintf.<br>
> - implement the two new functions naively in function of not-missing functions. These are slow and wasteful, but should work correctly at least.<br>
><br>
> I think the changes to core libc++ are minor, considering everything. Please comment if you think otherwise. On the other hand, please commit when you're OK with it.<br>
><br>
> This leads to the next problem(s):<br>
> - libc++ dll needs exports a la __cdeclspec(dllexport)/__cdeclspec(dllimport). See LLVM/Clang DLL discussions. Maybe using the same idea is possible.<br>
> - GCC (4.6) cannot inline vararg functions, thus is cannot fully compile libc++. On the other hand, Clang fails linking the dll due to a bunch of undefined references, among which cxxabi stuff, and C std library stuff. I'll investigate.<br>
> - MSVC has trouble parsing (I think) "inline namespace":<br>
> [ 4%] Building CXX object lib/CMakeFiles/cxx.dir/__/src/algorithm.cpp.obj<br>
> algorithm.cpp<br>
> M:\Development\Source\libc++\include\__config(14) : warning C4068: unknown pragma<br>
> M:\Development\Source\libc++\include\cstddef(46) : warning C4068: unknown pragma<br>
> M:\Development\Source\libc++\include\cstddef(50) : error C2143: syntax error : missing ';' before 'using'<br>
> M:\Development\Source\libc++\include\cstddef(50) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int<br>
> M:\Development\Source\libc++\include\cstddef(93) : error C2143: syntax error : missing ';' before 'namespace'<br>
> M:\Development\Source\libc++\include\cstddef(93) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int<br>
><br>
> Ruben<br>
><br>
</div></div>> <windows.patch><br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>