_t is a reserved namespace and nothing 3rd party (at least POSIX) should use it. We checked with Michal and building larger chunks of pkgsrc code had no negative effect with exposed max_align_t. I was responsible for bypassing the max_align_t libc++ definition and reusing our homegrown from stddef.h. The motivation was to avoid duplicated definition redefined differently (as long double) in libc++, as it caused a build failure. I didn't think about pre-C++11 build issues at that time. As discussed with the FreeBSD developers in the past, they recommended to just go for a solution like: #if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L #ifndef __CLANG_MAX_ALIGN_T_DEFINED typedef __max_align_t max_align_t; #define __CLANG_MAX_ALIGN_T_DEFINED #define _GCC_MAX_ALIGN_T #endif #endif and reuse the fallback in LLVM/GCC just as is. As we didn't provide such machine I disabled the fallback to our internal definition. I don't understand what we try fix here and what is broken (what fails to build, what is misbehaving) after exposing max_align_t. On 10.03.2020 12:38, Christos Zoulas wrote: > I've been following this discussion and it seems that: > > 1. upstream is not interested making the library support < c++11 > 2. finding the correct "max_align_t" is not obvious, but the library wants to > 3. "max_align_t" should not be exposed to < c++11 > > Given the above constraints, the simplest solution to move forward seems to be: > > 1. sed -i -e s/max_align_t/__max_align_t/g *.h > 2. edit the file where the typedef is defined and expose "max_align_t" if you are > compiling the library or if >= c++11 > > I don't see what all the fuss is about. > > christos > >> On Mar 10, 2020, at 7:30 AM, Kamil Rytarowski <n54%gmx.com@localhost> wrote: >> >> Signed PGP part >> On 09.03.2020 18:09, Joerg Sonnenberger wrote: >>> On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote: >>>> Upstream libc++ maintainers are against patching libc++. >>> >>> I'm buffled how you are arriving at this conclusion. Let me reiterate: >>> STOP MESSING UP THE TREE. >>> >>> Joerg >>> >> >> I'm sorry to come with these conclusions. I checked that the formal >> code owner (according to llvm/CODE_OWNERS.TXT) for libc++ is Marshall >> Clow (mclow), but he is not a very active in the development process and >> we are used to collaborate with other developers in the tree that review >> and feedback our patches (especially EricWF). >> >> >> <sanitizer.log> >
Attachment:
signature.asc
Description: OpenPGP digital signature