compiler standards (and/or min gcc version) supported with installed headers ?

[Andreas Jaeger]

On 01/03/2013 03:41 PM, Carlos O'Donell wrote:
> On 01/03/2013 03:21 AM, Andreas Jaeger wrote:
>> On 12/29/2012 05:57 AM, Mike Frysinger wrote:
>>> seems like something we should have spelled out in the manual and/or faq.
>>> what standards do we want to support with installed headers ?  and similarly,
>>> what min gcc version ?
>>>
>>> going by features.h, it seems like we support very old standards, which means
>>> it should be easy to support old gcc versions too.  a quick grep on my system
>>> shows we have __GNUC_PREREQ(2,0).
>>
>> based on the comments in this thread, I wrote the following proposal.
>> I've tried to separate the proposal into two discussion points:
>> First, what are the requirements. Second which compiler versions to
>> use.
>>
>>
>> * glibc needs a recent GCC compiler version to build itself (right now
>>    at least 4.3 required, 4.6 or newer recommended)
>>
>> * Userland applications and libraries that use glibc's headers and
>>    libraries can be build by a variety of compilers with the following
>>    notes:
>>
>>    - The compiler needs to support at least ISO C 90 (or C++98)
>>    - The compiler needs to support the type "long long"
>>    - GCC version X [1] is the oldest compiler supported in general (for some
>>      more recent hardware architectures a more recent compiler will be
>>      needed)
>>    - The glibc header files might include special optimizations for
>>      newer compiler versions which might not be available for older
>>      compilers
>>    - The header files for glibc use GCC Y [2] as baseline for such
>>      optimizations
>>    - Support for other compilers besides GCC might need extra patches
>>      which are welcome to be submitted for inclusion glibc
>>
>>    - For headers shared with gnulib, other conditions do apply (the
>>      requirements from gnulib to support even older compilers)
>>
>> To support different compilers, we would ideally not test - as today -
>> for a specific GCC version but for a specific feature.
>>
>> So, instead of __GNUC_PREREQ(x,y) to check for a specific version in
>> some header file, the advise is to add a macro to features.h, like
>> __GLIBC_HAVE_BUILTIN_COMPLEX and use that - and that macro definition
>> is dependend on compiler versions.
>>
>> [1], [2]:
>> I propose to use GCC 2.95.3 as baseline and GCC 4.3 - the same one we
>> use for building of glibc - for the optimization part.
>>
>> Would this work?
>
> Yes, this sounds good to me. I was just thinking about the supported
> vs. optimized issue and it really conflates two problems. We can
> support GCC 2.95.3 but not optimize for it. We can optimize for GCC 4.3
> and still support GCC 2.95.3.
>
> Thus for example we could get rid of the GCC 2.91 check for __builtin_memset
> in sysdeps/unix/sysv/linux/bits/sched.h and clean that up.

That raises a separate question - shall we assume that non-GCC compilers 
have __builtin_memset as well?

Otherwise the cleanup would be to change the got to use 
GLIBC_HAVE_BUILTIN_MEMSET - and define that for GCC.

> We don't win much because choosing to support GCC 2.95.3 isn't a very big
> bump, but we're a conservative project and we established guidelines here.
>
> I'd be really afraid to move to anything beyond GCC 3.x as a supported
> compiler that could be used with our headers.

 From my distribution point of view, I have no problems moving to a 
newer base,

Andreas
-- 
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
    GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)
     GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126