Well, this seems to be really going off topic. My only intention was to ask what the required/recommended host(system) compiler was and what documentation there was for that.
Branden Waldner wrote: > Is there an expected minimal system gcc version and if so, is it > documented? I couldn't find it noted anywhere. Nico Huber Wrote: > I don't think it's documented. As you already noticed, we depend on a > 3rdparty library (vboot), > so we actually don't know the minimum. I think it would be nice to document the expected compatible version(s), especially if it can done in a version/release relevant way. Trying to build "old" projects without any build system documentation can get pretty frustrating for example. Julius Werner wrote: > So I think the "official" rule is basically that the minimum requirement for > host utilities is the > same compiler and version that crossgcc uses, which I think makes some amount > of sense > (otherwise we'll just have to keep tracking and deploying two separate > versions). It's kind of hard to say it's a rule when it's not written anywhere. Also, while it sounds okay in theory to _require_ and test against a specific version of gcc, that ends up leading to some practicality issues in potentially needing to build a specific version of gcc on the host if it's not packaged, followed by the usual crossgcc build. Though in my situation, updating from Debian Stretch to Buster would likely fix the problem for now (and be significantly faster then compiling gcc as well (I would also likely already have most of the packages cached locally)). Following up on that, if Jenkins only tests using the same version of gcc as the current coreboot crossgcc, doesn't that leave out testing potential compatibility problems with newer (or older) versions of gcc (or clang?) that could be automatically tested for and identified as early as possible? Of course, that could end up with orders of magnitude more work for the build bot to do, which could end up being impractical. Julius Werner wrote: > FWIW I do seem to recall that this already came up back when > __attribute__((fallthrough)) was > added to vboot, and back then everyone seemed to agree that it was reasonable > to assume the > same version for the host compiler that we use in crossgcc. I would consider "assuming" the same host compiler as crossgcc to be a bug, since a coded check can do a lot better then that, with the the required maintenance of only being changed (automatically?) when crossgcc is updated. I don't recall when I first noticed the problem, but I "assumed" it was a regression that would be fixed, not that my system no longer had a new enough version of gcc. It was also confusing why vboot was being pulled in even though I didn't have it selected. While it sounds simple enough that cbfstool builds in crypto/hash support from vboot, it also doesn't really seem that big a deal to expect it to be able to option it out either. Of course there is some extra maintenance involved in that, but with cbfs being a stable for quite a while (according to recent posts at least), there shouldn't be too many changes? That is not necessarily tied in to the host gcc problem though - I realize that I need a newer version and didn't specifically complain about it, other then it being for rather trivial reasons. Also, an interesting reference for the required build environment is the linux kernel of course: https://www.kernel.org/doc/html/latest/process/changes.html (that url seems weird, but the page title is "Minimal requirements to compile the Kernel"). That likely requires some automated testing to verify and also probably ends up with a lot of work to maintain, but at least it's there. I hope I at least managed to add something of value to the conversation, though some of it just seems like me complaining... Branden Walder _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
