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