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

Ruben Van Boxem vanboxem.ruben at gmail.com
Thu Sep 22 12:35:47 PDT 2011


2011/9/22 Howard Hinnant <hhinnant at apple.com>

> Patch committed revision 140328.
>

Thanks!

Now that I've got your attention, on to more... involved... matters :-)

In order to support libc++'s current implementation using
cat[gets|open|close] and nl_types.h (which I ignored for now), I would need
to pull in some external code, namely mingw's libcatgets and a supporting
iconv library. These can all go under support/win32 and leave all other
platforms unchanged of course, and leave the rest of libc++ as coherent as
possible on all platforms. I understand Howard has an acceptable aversion to
including too much foreign code in libc++, and hope you can see the need for
this here.

There are some issues though:
 - libcatgets is licensed under GPLv2. If I can go through with this, I can
ask/plead/beg the original author to allow a license change or ask him to
make an exception for libc++. I know of no existing alternative.
 - for the iconv part, GNU libiconv is of course out of the question. There
are two projects of interest: APR-iconv (Apache License 2.0) and win-iconv
(BSD 2-clause license), the latter being tiny but primitive. The first is a
truly first class implementation as far as I can see, and with minor
refactoring could be included in the libc++ Windows build.
 - I am not an Open Source license lawyer, and do not know what would be
acceptable for libc++ in this regard.

I want to ask what's "best", before starting with the implementation. The
only real alternative is writing all this (ie catgets with supporting iconv
code) from scratch, which I don't see myself doing in the near to distant
future. Another way is to completely replace libc++ parts that use/rely on
these API's, but this would make libc++ a lot more assymetric across
platforms. In theory, these support files could help other platforms where
these API's are missing.

Please let me know what you think. Thanks!

Ruben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110922/4f4f19d5/attachment.html>


More information about the cfe-dev mailing list