Re: Fixing configure failures from newer gcc

[Greg Troxel <gdt%lexort.com@localhost>]

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?

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

It's not local 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 am treating "upstream packages should be portable and to the extent
feasible/reasonable rely only on POXIX and language standards" as
axiomatic.

> Instead (surely this is already true), just explain the problem:
>
> - file a bug upstream that the package doesn't build using BLAH
> compiler within pkgsrc
> include the obvious: an example of a warning, and mention the
> work-around used to mitigate it (which could include -std). perhaps
> include the weasel words "just a heads up ...", the implication being
> this is a fly-by bug report

Sure, but the bug is that it should have set std and didn't, and while
it's helpful to explain all the details, leaving out the bug isn't a
good idea.

This is really not about pkgsrc and not about NetBSD; it's about a
package's first contact with a gcc that defaults to C23, it seems.

> There's a good chance that upstream is simply not aware of the problem
> (esp. on debian derived systems which seem to always be out-of-date,
> and llvm can still be considered obscure).

Yes, it's Linuxy to build on the system in front of you and not really
experience portability either as a problem or conceptually.  People on
!linux almost always experience enough portability issues to have a base
level of understanding.

You are right that I should have been slightly more verbose.  How about:

  - Find or file a bug upstream that it doesn't set -std, and thus fails
    to compile e.g. under gcc14 which assumes C23.