At Sat, 15 Jun 2024 06:54:55 -0400, Greg Troxel <gdt%lexort.com@localhost> wrote:
Subject: Re: dealing with inevitable warnings from new compilers on old code
>
> "Greg A. Woods" <woods%planix.ca@localhost> writes:
>
> > I'm going to try moving this to tech-pkg for further discussion
>
> You didn't; you cross posted....
Yes, but that's how a thread is moved from one list to another, with the
added step of setting Reply-To, which I did.
Sadly your mailer doesn't seem to honour the Reply-To header given in my
email. Please try to make it do so! (GNUS should know better!)
So, actually, you are (or rather your mailer is) the one who cross-
posted unnecessarily. :-) You also didn't have to CC me personally, and
I specifically did not include my address in the Reply-To for this reason.
> > Now that USE_LANGUAGES is officially(?) deprecated
>
> It is not, but what USE_LANGUAGES used to mean is now separated into
> multiple pieces, and things are vastly better than they used to be.
Sorry I meant "deprecated specifically for choosing a required language
standards level by setting, or causing to be set, the desired value for
the "-std=" flag".
From mk/compiler.mk:
# There is deprecated support for expressing a specific language
# dialect (e.g. c++17) in USE_LANGUAGES. This both requires a
# compiler that supports that dialect, and adds -std= flags via
# the wrappers. (Instead, following the documentation below,
# the language dialect should be added to USE_C_FEATURES or
# USE_CXX_FEATURES to require a compiler with support, and if
# the package does not add -std flags itself, then FORCE_C_STD
# or FORCE_CXX_STD should be set.)
So it is actually telling us to use FORCE_C_STD to set the desired
language level when necessary.
> USE_C_FEATURES/USE_CXX_FEATURES have tokens that can represent either
> language family members (e.g. c++17) or specific language features (that
> are often formally part of a family member, but are separated), like
> filesystem.
As I said, USE_CC_FEATURES has an _opposite_ purpose to the present need
to _lower_ the language level and so it is clearly useless for this
purpose. Besides it currently only sets the minium compiler for GCC,
and it doesn't affect any other compiler than GCC, nor does it set
"-std=".
> FORCE_{C,CXX}_STD adds --std=foo via the wrappers. As I read the
> documentation and the code, this is independent of requiring a compiler
> that needs that. That reading matches my inuition about how this ought
> to be. So a C++17 program that fails to set --std=c++17 needs:
>
> USE_LANGUAGES= c++
> USE_CXX_FEATURES= c++17
> FORCE_CXX_STD= c++17
I would guess that pkgsrc would not be workable on any platform where
the default C compiler was an ancient GCC 3.x release, so in general
it's not likely necessary to ever have to combine USE_CC_FEATURES (as it
is currently implemented) and FORCE_C_STD to downgrade the language
level, though obviously there isn't any harm in it either, and I guess
it could be updated to catch out any compiler that had dropped support
for legacy language levels.
The example for legacy code would of course be something more like:
USE_LANGUAGES= c
USE_CC_FEAGTURES= gnu90
FORCE_C_STD= gnu90
> If a program is written in some particular C language family member (c11
> say) and it does not probe for --std=c11 at configure time and pass
> --std=c11 at compile time, then it is buggy.
Sure, but are you going to fix the package, or tweak the pkgsrc Makefile?
After all the package built just fine before newer compilers came out.
It's not the package's fault for pkgsrc to be trying to use a newer
compiler than the package's author ever even heard of.
> FORCE_C_STD=c11 is a
> pkgsrc workaround to cause --std=c11 to be passed to the compiler, and
> no more.
Exactly.
The only problem is that it doesn't cleanly deal with the issue of a
platform upgrade forcing a newer compiler that defaults to a newer
language standard level and which causes errors on previously "clean"
code.
Ideally there could be a (mostly internal) "DEFAULT_C_STD" setting too
(i.e. not for use in individual package Makefiles), which would be
automatically chosen based on the current platform's default compiler
and some overall assessment of the state of legacy code in all packages.
> If a program has code that triggers warnings when compiled with a
> non-buggy compiler that supports the documented language family member
> and perhaps FORCE_C_STD, and also sets -Werror, that's a separate issue,
> but it really isn't about the language family.
I think you may not be understanding the problem fully.
Please have a review of the thread with the subject "next steps from
recent macOS fallout" started back on 2024/04/04.
The post that (re)started this was about the same fallout, but of course
on Linux with GCC.
Amitai was being extremely conservative in trying to just prevent the
new errors one by one and perhaps not really fully appreciating that the
underlying cause of the problem should be dealt with in a more general
and compiler-agnostic fashion.
The real problem here is one of needing to ask default compilers to
_downgrade_ their language level, NOT one about trying to provide a
newer compiler for packages that might be ahead of the game (i.e. ahead
of the default compiler on a given platform).
Also, it is the newer GCC and Clang releases that are implicitly
forcing, in effect, -Werror for some of their new warnings and as a
result causing previously fine packages to suddenly fail.
We can be confident that most C packages in pkgsrc, and specifically
those that don't supply "-std=" themselves, are able to be built and
work with a GNU99 compiler, and for the moment we know that the newer
compilers pkgsrc is likely to encounter will not force -Werror for new
warnings if they're told to downgrade the language level with
"-std=gnu99", so if pkgsrc is used on a platform with one of these newer
compilers then ideally pkgsrc should provide a _default_ "-std=gnu99"
setting (but not override those packages the provide their own "-std=").
Perhaps the problem is small enough to just use FORCE_C_STD in those
packages that blow up with newer compilers, or maybe a DEFAULT_C_STD is
a better solution (it would be a better long-term solution I think).
I suspect the same applies for C++, so wash, rinse, and repeat with
_CXX_ as well.
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpBdwlSlH1ph.pgp
Description: OpenPGP Digital Signature