Re: Fixing configure failures from newer gcc

[Paolo Vincenzo Olivo <vins%NetBSD.org@localhost>]

On 25/10/19 01:24AM, Greg A. Woods wrote:
> At Sat, 18 Oct 2025 23:01:29 -0400, Andrew Cagney <andrew.cagney%gmail.com@localhost> wrote:
> Subject: Re: Fixing configure failures from newer gcc
> >
> > Except programs, are not written to a language standard.  They are
> > written to a combination of the available compilers, libraries, and
> > coding standards.  And that is a constantly moving target that doesn't
> > say in the --std=cNN box.
>
> [...] 
>
> So now we need to tell the compiler to back off by giving it the
> appropriate "-std=" option, i.e. make the maximum language level
> explicit.
> 
> Note too that unlike the attempts to use "-Wno-*" the use of "-std=" is
> fully portable across all newer versions of any compilers that were
> previously used to build such legacy code within the pkgsrc.
> 
> [...]
> 

I agree on the fact that silencing warnings/errors on a per package
basis is not ideal, as they will most likely be ignored and pass
unnoticed from that moment on. While I don't support enforcing policies
which break previously working code, some of the newly introduced
-Werror standards in GCC14 point the finger towards bugs which may be 
worth fixing and/or reporting upstream (e,g, incompatibile pointer types
and implicit function declaration warnings).

I fixed some of my packages after seeing the first SmartOS bulk builds
using GCC14 being published, but the amount of work to be carried out –if
we hypothetically decided to bring pkgsrc in a state where it's fully
compliant with the expectations imposed by newer compilers– is huge.

Less mainstream platforms, including NetBSD and SunOS, are more likely
to get new breakages because of software built and tested on Linux only. 

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.  

As a side note, recently I decided to pass `-Wno-deprecated-declaration'
to a couple of packages I maintain. I'm referring to software written
for OpenBSD/LibreSSL, and using OpenSSL 3.x + a LibreTLS shim on pkgsrc.
OpenSSL 3 deprecated several functions which are still in use in
LibreSSL [0], so it seems reasonable to silence deprecation warnings,
as they arise from inherent incompatibilities between the two APIs.
I wonder if silencing is to be considered acceptable in such edge cases.

Regards,
PVO

[0] See https://docs.openssl.org/3.0/man7/migration_guide/