[Bug build/27596] New: bits/libc-header-start.h is C++ header-unit unfriendly

["nathan at acm dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=27596

            Bug ID: 27596
           Summary: bits/libc-header-start.h is C++ header-unit unfriendly
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: nathan at acm dot org
                CC: carlos at redhat dot com
  Target Milestone: ---

bits/libc-header-start.h is, IIUC, morally glibc's config.h.  It has protection
in it so that it is only included from within glibc:

#ifndef __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION
# error "Never include <bits/libc-header-start.h> directly."
#endif

#undef __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION

This makes it unfriendly to being compiled as a stand-alone C++ header unit,
unless you add -D__GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION on the command
line.  But that does raise some questions:
a) does it ever do more than define/undefine macros?
b) does it ever produce differing sets of macro definitions *within a single
(consistent) build*.

#b breaks a header-unit requirement, which would be unfortunate.

We can work around this issue by textually including it, so it is not a
header-unit.  But that leads to:

1) inefficencies in building, as now each includer, built as a header unit,
will end up providing the macros and the ultimate importer will check all those
macro definitions are the same, lazily at the point of expansion.

2) If #b above is true, those sets of definitions/undefinitions could conflict,
leading to compilation errors at the point of expansion.  We have not observed
this, but we've only done minimal testing right now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.