tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

default C versions

From recent commit messages where Taylor (probably) fixed libuv building
on EL7, I wonder if there is a systematic way to avoid these issues.
As I understand it code in EL7 was frozen in 2013 or maybe 2012, so it's
"wicked old" as we say in Boston.

My understanding is hazy, but since I haven't seen anything on the list,
I think:

  Lots of packages probably need a C99 compiler, but aren't tagged as
  such -- because pretty much every system has a C99 compiler and
  compiles in C99 by default, because in 2023, C99 is beyond normal.

  I am guessing EL7 uses a compiler that uses C90 (== C89) by default.

  It seems obviously buggy in the larger ecosystem that different
  compilers have different defaults in terms of which language they are
  compiling for (unapologetically taking the view that C is a language
  family and C99 is a language).

and thus I wonder if the wrappers should be passing --std=c90 when there
is no c99 or higher in USE_LANGUAGES.  That would in theory cause
packages that need c99 to fail even when c99 is default, which would get
the mis-tagging of USE_LANGUAGES fixed earlier.

An alternative would be to declare that c99 is normal and c90 deficient
and have the wrappers on systems with really old compilers add
--std=c99, which is sort of like putting c99 in the default
USE_LANGUAGES, but messier, and that doesn't seem great to do ad hoc.

This is a half-baked idea, and I am curious what others think.

Home | Main Index | Thread Index | Old Index