tech-pkg archive

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

Re: Fixing configure failures from newer gcc



On Sun, 19 Oct 2025 at 09:29, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
> Paolo Vincenzo Olivo <vins%NetBSD.org@localhost> writes:
>
> > The idea of applying global pkgsrc CFLAGS in mk/ to mitigate build
> > failures appears reasonable. It could involve both setting a global
> > `std=xxx', and some `-Wno-error=xxx' flag, which at least doesn't
> > obfuscate the warning.
>
> We should first address the biggest issue, which I think is:
>
>   - programs written to C99 (or some later std, but not C23)
>   - those programs do not probe for and use --std
>   - they have problems when built as C23
>
> pkgsrc has had a mechanism to deal with this for several years, thanks
> to nia@ who implemented it after much discussion.
>
> 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

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

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

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).


Home | Main Index | Thread Index | Old Index