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

[Andreas Jaeger]

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