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

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

[nathan at acm dot 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.

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

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
The handling of __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION is a check 
to discourage external users from using something that's not a public API, 
rather than something strictly required.

bits/libc-header-start.h will produce different macro definitions when 
included with different feature test macros defined.  It's valid for that 
to occur within the compilation of a single translation unit - for one of 
the ISO C feature test macros to be defined after some headers have been 
included and before others are included.  The peculiarities of how those 
ISO C feature test macros are defined are why this header is separate from 
features.h and can't have multiple-include protection.

If the rules that the definitions from a header depend on what feature 
test macros were defined when *that header* is first included (as opposed 
to it being required to define feature test macros before including any 
standard header, as in POSIX) are problematic for C++, that seems like a 
good thing to raise on the C/C++ liaison mailing list.  Or is the issue 
only with the particular approach to implementing that requirement, rather 
than with the requirement itself?

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

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

[nathan at acm dot org]

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

Nathan Sidwell <nathan at acm dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |NOTABUG
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Nathan Sidwell <nathan at acm dot org> ---
thanks Joseph, Yeah I noticed the lack of #if guarding, but forgot to mention. 
This is indeed a 'non-importable header', and must be treated as text on each
inclusion.  We'll mark it so in our builds.

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