This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/4] Miscellaneous 'safe' testsuite changes.


On 02/20/2017 10:34 AM, Zack Weinberg wrote:
> On Mon, Feb 20, 2017 at 9:52 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>> On Mon, 20 Feb 2017, Zack Weinberg wrote:
>>> atomic.h cannot be used by code compiled under _ISOMAC, but
>>> stdatomic.h can.  There are quite a few tests that use atomic.h; most
>>> of them were not straightforward to change to stdatomic.h, but
>>> nptl/tst-join7.c was, so I did that.
>>
>> stdatomic.h is not available before GCC 4.9, and our minimum version for
>> building glibc is 4.7 (although you can't use build-many-glibcs.py with
>> versions before 4.9 because of missing features for bootstrapping cross
>> compilers with glibc, in particular --with-glibc-version).
> 
> I don't recall exactly what was wrong with atomic.h in _ISOMAC mode
> but I suspect it is not trivial to fix.  I *could* just give up here
> and move tst-join7 to tests-internal, but if the "new policy" is to
> use C11 atomics, perhaps that is sufficient reason to bump the minimum
> version requirement to 4.9??

Please restart this in a different thread, for context:

C11 (internally, not exposed via headers):
https://sourceware.org/glibc/wiki/Consensus#Standards_we_use

RFC: requiring GCC >= 4.7 to build glibc
https://sourceware.org/ml/libc-alpha/2015-08/msg00851.html

Google developers appeared to be blockers here because of Ubuntu 14.04LTS
using gcc 4.8, and that should be verified again, include Mike Frysinger
to answer that question.

Paul Eggart recommended gcc 4.9.

Upstream GCC has no FSF supported 4x. branches, they are all 5/6/7 support.

Therefore if we are going to move the minimum required build compiler it
should be to some supported FSF branch e.g. gcc 5.4.

I think that users expecting new new glibc to build with old old gcc have
their expectations set wrong. They should be using old glibc branches and
working on backports if they need ABI/API-neutral fixes.

This has nothing to do with the compiler used to build the applications
though, there we need to continue to support very old gcc's.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]