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

[Andreas Jaeger <aj at suse dot com>]

On 01/02/2013 10:59 AM, Mike Frysinger wrote:
> 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

Agreed.

>   - 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.

Indeed.

> 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.

Indeed. But we should have a baseline - and if we all agree on 2.95.3 
(on those architectures that support that - I guess x86, Sparc, Alpha - 
for sure not on x86-64, s390x, ARM64) that's fine.

The baseline is needed for adding new code so that we all agree what 
might need special handling and what not.

> > 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).

Still, it needs somebody to step up and check.

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