| Message ID | 03f284a2-cc9b-4950-89b7-f9feaac0e129@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Config.mk: correct gcc5 check | expand |
On 31.03.2025 14:01, Jan Beulich wrote: > Passing the -dumpversion option to gcc may only print the major version > (for 4.x.y it printed major and minor, which in nowaday's scheme is then > indeed just 5 for 5.x). I meanwhile notice that my self-built compilers print 3 digits, so there really is a point to doc saying "Depending on how the compiler has been configured it can be just a single number (major version), two numbers separated by a dot (major and minor version) or three numbers separated by dots (major, minor and patchlevel version)." I've locally changed the above to (my system 4.x.y printed major and minor, which in nowaday's scheme is then indeed just 5 for 5.x, which in turn is what my secondary system compiler does) Jan
On 31/03/2025 1:06 pm, Jan Beulich wrote: > On 31.03.2025 14:01, Jan Beulich wrote: >> Passing the -dumpversion option to gcc may only print the major version >> (for 4.x.y it printed major and minor, which in nowaday's scheme is then >> indeed just 5 for 5.x). > I meanwhile notice that my self-built compilers print 3 digits, so there > really is a point to doc saying > > "Depending on how the compiler has been configured it can be just a single > number (major version), two numbers separated by a dot (major and minor > version) or three numbers separated by dots (major, minor and patchlevel > version)." > > I've locally changed the above to > > (my system 4.x.y printed major and minor, which in nowaday's scheme is > then indeed just 5 for 5.x, which in turn is what my secondary system > compiler does) Oh, that's useless. Do all versions provide __GNUC_MINOR__ correctly? ~Andrew
On 31.03.2025 17:22, Andrew Cooper wrote: > On 31/03/2025 1:06 pm, Jan Beulich wrote: >> On 31.03.2025 14:01, Jan Beulich wrote: >>> Passing the -dumpversion option to gcc may only print the major version >>> (for 4.x.y it printed major and minor, which in nowaday's scheme is then >>> indeed just 5 for 5.x). >> I meanwhile notice that my self-built compilers print 3 digits, so there >> really is a point to doc saying >> >> "Depending on how the compiler has been configured it can be just a single >> number (major version), two numbers separated by a dot (major and minor >> version) or three numbers separated by dots (major, minor and patchlevel >> version)." >> >> I've locally changed the above to >> >> (my system 4.x.y printed major and minor, which in nowaday's scheme is >> then indeed just 5 for 5.x, which in turn is what my secondary system >> compiler does) > > Oh, that's useless. > > Do all versions provide __GNUC_MINOR__ correctly? I'm entirely sure they do. Jan
--- a/Config.mk +++ b/Config.mk @@ -125,9 +125,9 @@ define cc-ver-check-closure endif endef -# Require GCC v5.1 as the project global baseline -check-$(gcc) = $(call cc-ver-check,CC,0x050100,"Xen requires at least GCC 5.1") +# Require GCC v5 as the project global baseline +check-$(gcc) = $(call cc-ver-check,CC,0x050000,"Xen requires at least GCC 5") $(eval $(check-y)) ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \ grep -q build-id && echo n || echo y)
Passing the -dumpversion option to gcc may only print the major version (for 4.x.y it printed major and minor, which in nowaday's scheme is then indeed just 5 for 5.x). Fixes: 40458f752550 ("Xen: Update compiler baseline checks") Signed-off-by: Jan Beulich <jbeulich@suse.com>