From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 82B35385781A; Wed, 17 Mar 2021 13:35:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82B35385781A From: "nathan at acm dot org" To: glibc-bugs@sourceware.org Subject: [Bug build/27596] New: bits/libc-header-start.h is C++ header-unit unfriendly Date: Wed, 17 Mar 2021 13:35:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: build X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nathan at acm dot org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: glibc-bugs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Glibc-bugs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 13:35:17 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27596 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 protec= tion in it so that it is only included from within glibc: #ifndef __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION # error "Never include 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 com= mand 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 t= hose macro definitions are the same, lazily at the point of expansion. 2) If #b above is true, those sets of definitions/undefinitions could confl= ict, leading to compilation errors at the point of expansion. We have not obser= ved this, but we've only done minimal testing right now. --=20 You are receiving this mail because: You are on the CC list for the bug.=