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

[Ruben Van Boxem]

2011/9/22 Eli Friedman <eli.friedman at gmail.com>

> On Thu, Sep 22, 2011 at 12:35 PM, Ruben Van Boxem
> <vanboxem.ruben at gmail.com> wrote:
> > 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!
>
> MSVC doesn't provide a non-trivial implementation of
> std::messages::do_open etc., so I don't see why it matters if libc++
> does not provide one on Windows.
>

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?

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