tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Fixing configure failures from newer gcc
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.
> 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.
My take is that if you the maintainer have analyzed and understood, it's
fine. But there should be a comment in the pkgsrc makefile where the
-Wno is added that explains the situation well.
Home |
Main Index |
Thread Index |
Old Index