Re: Fixing configure failures from newer gcc

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Sun, 19 Oct 2025 at 13:17, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Andrew Cagney <andrew.cagney%gmail.com@localhost> writes:
>
> >> See FORCE_C_STD in mk/compiler.mk.  If a program is written to C99 and
> >> doesn't add -std, our *existing practices* say we should:
> >>
> >>   - Set FORCE_C_STD=c99 (or gnu99)
> >>   - If the program is in C99 but the README doesn't say that, file a bug
> >>     upstream about that.
> >>   - Find or file a bug upstream that it doesn't set -std
> >>   - Add a comment that upstream doesn't set std, with the bug report URL
> >>
> >>   - Probably, file a bug upstream that it doesn't build as C23 under gcc14.
> >
> > This feels like a CLM:
> >
> >  - Find or file a bug upstream that it doesn't set -std
>
> CLM?

Career Limiting Move - making oneself unpopular.

> > Having a downstream packaging system try to force local policy on the
> > upstream developers never ends well.
>
> It's not local policy.

But -std is being discussed as a local pkgsrc policy.

> It's a failure to work in an environment where
> it should work, because the world has decided that if you just run cc,
> you will get some C std by default but you don't know which one.
> Therefore unless your code is compatible with every C std, from C89 to
> C23, then your package is buggy.

I think a more reasonable expectation is that a package be buildable
with the default settings of mainstream compilers less than 5 years
old (i.e., LTS).   While buildable with c23, the package still needs
to wait a few years before adopting c23 features (like bool being
defined).