[swift-dev] need help with GLibc module map problem

Dmitri Gribenko gribozavr at gmail.com
Fri Jun 3 12:05:22 CDT 2016

On Fri, Jun 3, 2016 at 8:23 AM, David P Grove <groved at us.ibm.com> wrote:
> Dmitri Gribenko <gribozavr at gmail.com> wrote on 06/02/2016 06:19:33 PM:
>> Could you check if there are multiple definitions of off_t or mode_t
>> in different headers guarded by macros?  Something like this,
>> duplicated across several headers:
>> #if !defined(_OFF_T_DEFINED)
>> typedef __off_t off_t;
>> #define _OFF_T_DEFINED
>> #endif
>> This is a frequent pattern used in C headers, but it is an antipattern
>> for modules.  With modules, all headers that are included into the
>> module get #included into a single translation unit and compiled into
>> a module, so only one of those typedefs will get activated (let's say
>> in foo.h), and the other one will get hidden because it is seen second
>> in the translation unit (let's say the one in bar.h gets hidden).  If
>> you then import just the submodule for bar.h, the off_t definition
>> won't be visible, because it was #ifdef'ed out.
>> There are fragile solutions to this (like including a header that
>> happens to fix the build this time), but the only real fix is to make
>> sure that there is only one place where a declaration can be located
>> in a module, regardless of the set of headers.
> Thanks for the response Dmitri.  Yes this is indeed the case.  On my Ubuntu
> 15.10 system there are conditional typedefs of this flavor in 5
> /usr/include/* header files for mode_t and in 6 header files for off_t.
> What do you recommend I should try to work around the messy state of the
> system headers?

Try including sys/types.h before including any other header that can
define these types.  (For example, you can just include it at the

Another thing to try is to move sys/types.h to the very top in the
modulemap, to make sure that it gets included first, and gets to "own"
the definition.

But the only real fix is to work with EGLIBC to make the headers
module-friendly.  You might want to ask on the cfe-dev, the Clang dev
list, if there are other people interested in this.  (I think Google
might be, they are contributing heavily to the Clang modules


(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

More information about the swift-dev mailing list