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: compiler standards (and/or min gcc version) supported with installedheaders ?


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


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