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

[Mike Frysinger <vapier at gentoo dot org>]

On Wednesday 02 January 2013 03:22:06 Andreas Jaeger wrote:
> On 12/30/2012 02:22 AM, Mike Frysinger wrote:
> > On Saturday 29 December 2012 10:37:55 Joseph S. Myers wrote:
> >> On Fri, 28 Dec 2012, 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 ?
> >> 
> >> Practically, GCC versions before 2.7.2.3 are fairly irrelevant because
> >> they didn't support glibc 2.x with the Linux kernel (or GNU Hurd) - and
> >> for architecture-specific headers, the minimum versions may be newer on
> >> similar grounds.  Some headers however may be shared with gnulib, where
> >> older compilers may be relevant.
> >> 
> >> I have suggested (in the projects list
> >> <http://sourceware.org/glibc/wiki/Development_Todo/Master> - note that
> >> the ideas listed there are not necessarily fully formed project
> >> suggestions and may not all have consensus) that __GLIBC_HAVE_LONG_LONG
> >> should be removed - that support for "long long" should be considered a
> >> required feature for use of the installed headers.
> > 
> > gcc-2.95.3 is the oldest version i care about.  and it supports long
> > long.
> 
> With us moving to require Linux 2.6.16 as oldest release (which is from
> 2006), we should be able to require a newer GCC version as well.
> 
> Btw. GCC 4.1 was released around the same time as Linux 2.6.16 in early
> 2006.

the use case for older compilers (iterating so we're all on the same page):
 - building binaries with "minimal" dependencies to make the result more 
portable
 - compile old software that is only supported/working with older compiler
 - any other reason ?

your points here highlight that the first item doesn't really matter as an old 
gcc w/modern glibc is pointless.  you'd have to play ugly linking games in 
order to get the older symbol versions, and even then you'd have to make sure 
the structures in the headers line up.  it's an unsupportable mess which means 
if you want to do this, you have to use an old glibc which means we no longer 
have to worry about it.

the second point is harder to quantify.  i've seen one or two reports of that 
nature wrt gcc-2.95.3, but since i punted the previous bug (related to nptl's 
pthread.h not working), i'm not sure how many people still have this issue.  
or if they search bugzilla for the error, see it, and then move on rather than 
commenting further.

i think we should also be practical here: if the effort is low, then leave it 
in.  but if it becomes really burdensome/ugly, then drop it.

> We do have to take care that we support other compilers - besides GCC -
> as well and that our removal of support for older GCC in installed
> headers does not break other compilers. But since no other compiler
> vendor is involved here and were few of us have access to other
> compilers, we might need to fix up headers after we receive bug reports.

clang & icc are the big ones nowadays that i think we can be a bit more 
proactive in checking that we don't break as we know they are actively 
utilized.  the rest we can be reactive (i.e. wait for them to complain as you 
suggest).
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.