At Sun, 01 Sep 2024 13:30:07 +1200, Lloyd Parkes <lloyd%must-have-coffee.gen.nz@localhost> wrote:
Subject: Re: Host requirements to build the Tools binaries
>
> On Sat, 2024-08-31 at 14:10 -0700, Greg A. Woods wrote:
> > I.e. did you add the appropriate "-std=gnu89", "-std=gnu99", or
> > whatever is right for an older GNU Make?
>
> I thought about that for the rest of tools but that would involve
> working out what the host compiler is so that we don't pass GCC options
> to something that doesn't want them. It just didn't seem clean to me.
By "appropriate" I meant "based on the host compiler's features". When
building NetBSD's toolchain the build must choose and use the
appropriate options to get the host's compiler to do the right thing for
a given tool's code base. I.e. also choose the right options on a
per-tool basis of course, based on what language features (or
extensions) the tool's code contains.
Note that the "gnu" in "-std=gnu99" isn't a GCC option per se. Most, if
not all modern, compilers these days support GNU extensions and will
enable them using the same "-std=gnu99" option (if indeed they are not
already enabled by default). This is true for Clang of course, as well
IBM's xlc, Solaris Developer Studio C, Intel C, and others I've
forgotten about.
So, to sum up:
1. determine the language level and possible extensions used in each
particular tool's code.
2. determine which language levels and extensions a given supported
build host's compiler provides
3. select compiler options (i.e. primarily the "-std=" value) for
each tool from the matrix above
This is already effectively done in xz-include/Makefile.inc (as it is
extremely unlikely that any supported host compiler won't offer C99 so
it need not be conditioned on which compiler is being used). Adding
that same line (perhaps with "c90") to a new gmake/Makefile.inc should
have been the first step in building the NetBSD toolchain on a new
GNU/Linux with the newest GCC (or, e.g. newest FreeBSD with the newest
Clang). All of the NetBSD toolchain can be considered legacy code when
facing a new build host's latest-greatest compiler.
> It's not so much that the code was written to an older language
> standard, it's more that back then the programmers just went YOLO.
Huh? Actually the code _was_ written to an older version of the
language because the newer standards were not even in existence, let
alone supported, when the code was written and released!!!
Take for example GNU Make 3.81 -- it was released in 2006. C11 didn't
exist yet, and C17 and C23 weren't even in anyone's imagination yet. If
it even uses any C99 features I'd be surprised. It may not even need
GNU90, just "-std=c90" may suffice (it is/was after all designed to be
quite portable).
By the time C99 was widely available it was highly likely that some
existing code even required "-std=c90" to compile properly.
Note that code such as GNU Make may _also_ need "-D_GNU_SOURCE", but
that's a subtly different issue and one dependent on what the build
host's native include files and libraries are (i.e. nothing to do with
the compiler itself nor compiler-specific language-level options).
> > It is my current (somewhat limited) experience with testing my own
> > legacy code and some few legacy packages against GCC-14 and Clang-16
> > that there are no "new" problems with this code when I tell those
> > compilers to conform to the appropriate language standard for the
> > code
> > being compiled.
>
> I agree.
What are you agreeing with? It doesn't seem you're agreeing fully with
me that one should/must use the appropriate "-std=" option for legacy
code.
I don't mean to be harsh, but I really can't even begin to understand
why anyone would object to or balk at using the appropriate "-std=" for
all code, including especially legacy code. That's what that option is
there for, and why it is a _standard_ option across compilers. It's the
"way out" for all the compiler vendors who have pushed, prodded, and
forced new incompatible features into the new language standards.
I suppose if one has the desire to port legacy code forward to a new
language standard when using a new compiler then one might choose to
patch it to eliminate any new errors or even warnings, but if one's goal
is just to build a working program from legacy code, even when using a
bleeding edge compiler that defaults to a newer language standard, then
one _MUST_ set the appropriate "-std=" option for the code in question
else be faced with all those new but unnecessary errors and warnings.
> Despite my previous comment about host compilers, I suspect that most
> people are building with GCC even if that isn't their vendor supplied
> compiler.
Well, perhaps, or Clang.
> Also I'm sure I've seen vendor compiler accept GCC command
> line options because too many software authors assume every compiler is
> GCC.
Indeed. Usually that includes also using/allowing "-std=gnuNN" (even if
the compiler doesn't already enable GCC extensions by default).
--
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:
pgpvp6ZNvzywY.pgp
Description: OpenPGP Digital Signature