This is the mail archive of the 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/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 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
<> - 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

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.

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 Jaeger aj@{,} 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]