[cfe-dev] How do I try out C++ modules with clang?

[Sean Silva]

On Wed, Oct 22, 2014 at 3:22 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Sean Silva <chisophugis at ...> writes:
>
> > Stephen, thanks for being a brave guinea pig here :)
>
> No problem!
>
> With the define I get more errors of the form:
>
> $ clang++ -E -fmodules -fmodules-cache-path=cache -D_USE_EXTENDED_LOCALES_
> test.cpp
> # 1 "test.cpp"
> # 1 "<built-in>" 1
> # 1 "<built-in>" 3
> # 325 "<built-in>" 3
> # 1 "<command line>" 1
> # 1 "<built-in>" 2
> # 1 "test.cpp" 2
> While building module 'std' imported from test.cpp:6:
> While building module 'Darwin' imported from
> /Users/ske/dev/prefix/bin/../include/c++/v1/__config:23:
> In file included from <module-includes>:3:
> In file included from /usr/include/ctype.h:384:
> /usr/include/xlocale/_ctype.h:35:50: error: unknown type name 'locale_t'
> unsigned long           ___runetype_l(__darwin_ct_rune_t, locale_t);
>                                                           ^
> /usr/include/xlocale/_ctype.h:36:53: error: unknown type name 'locale_t'
> __darwin_ct_rune_t      ___tolower_l(__darwin_ct_rune_t, locale_t);
>                                                          ^
>
>
This is probably being caused because you aren't actually supposed to
define _USE_EXTENDED_LOCALES_ on the command line. It's an internal macro,
and defining it on the command line causes the system headers module to be
built with that defined. When the system headers module is being built,
that define is causing ctype.h to behave as though xlocale.h has already
been included, even though it hasn't (locale_t is defined in xlocale.h and
ctype.h ends up needing locale_t when _USE_EXTENDED_LOCALES_ is defined).

-- Sean Silva


>
> Actually I think I hit similar errors from files in /usr/include when I
> tried this a few weeks ago on linux, and I think my solution was to add a
> modulemap in /usr/include for a few things. I'll check that in a few days.
>
> This patch allows me to build the libcxx module:
>
> diff --git a/include/ios b/include/ios
> index ff79998..e5dc654 100644
> --- a/include/ios
> +++ b/include/ios
> @@ -213,6 +213,7 @@ storage-class-specifier const error_category&
> iostream_category() noexcept;
>
>  #include <__config>
>  #include <iosfwd>
> +#include <cstdlib>
>  #include <__locale>
>  #include <system_error>
>
>
> Though this stuff is very fiddly, and I have not yet grokked the whole
> connection/problem between modules and defines (I haven't passed the 'it
> basically works' barrier yet in order to grok that :) ), so I don't know if
> the above patch is the right approach.
>
> I am surprised that this problem has survived as I thought it would be an
> obvious "step 1" for anyone trying modules on mac. I guess either it's been
> tested so far on a different kind of system, or whoever added the modulemap
> for libcxx only tested it on linux. A unit test could be added in libcxx
> which attempts to build a module for it, right?
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141022/a0de7e13/attachment.html>