k...@munnari.oz.au (Robert Elz) writes:
>The way you have it coded, I suspect that 9.1 binaries will appear to
>be 9.1.0 instead (the ver_patch data is always appended for ver_maj >= 9).
True. Here is a patch that ignores a zero patch level.
Index: external/bsd/file/dist/src/readelf.c
===================================================================
RCS file: /cvsroot/src/external/bsd/file/dist/src/readelf.c,v
retrieving revision 1.25
diff -p -u -r1.25 readelf.c
--- external/bsd/file/dist/src/readelf.c 9 Apr 2021 19:11:42 -0000
1.25
+++ external/bsd/file/dist/src/readelf.c 21 Sep 2022 23:17:49 -0000
@@ -456,7 +456,13 @@ do_note_netbsd_version(struct magic_set
if (file_printf(ms, " %u.%u", ver_maj, ver_min) == -1)
return -1;
- if (ver_rel == 0 && ver_patch != 0) {
+ if (ver_maj >= 9) {
+ ver_patch += 100 * ver_rel;
+ if (ver_patch != 0) {
+ if (file_printf(ms, ".%u", ver_patch) == -1)
+ return -1;
+ }
+ } else if (ver_rel == 0 && ver_patch != 0) {
if (file_printf(ms, ".%u", ver_patch) == -1)
return -1;
} else if (ver_rel != 0) {
>However, I wonder why this kind of info is embedded in ELF files, what
>point does that have? Maybe it would be better to have them just say
>x.99 (and forget the kernel ABI bump number) ?
The note has little value, best it can do is identify from which
release the binary came, in case you have a mixed installation. And
then the full version number is required.
