Re: pkg: Newer FreeBSD version for package... but why?
- Reply: Christer Edwards : "Re: pkg: Newer FreeBSD version for package... but why?"
- Reply: Ronald Klop : "Re: pkg: Newer FreeBSD version for package... but why?"
- Reply: Andriy Gapon : "Re: pkg: Newer FreeBSD version for package... but why?"
- In reply to: Andriy Gapon : "Re: pkg: Newer FreeBSD version for package... but why?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 13 Jul 2022 18:33:10 UTC
On 7/13/22 3:17 AM, Andriy Gapon wrote:
> On 2022-07-13 13:09, Michael Gmelin wrote:
>>
>>
>> On Wed, 13 Jul 2022 10:29:06 +0300
>> Andriy Gapon <avg@FreeBSD.org> wrote:
>>
>>> # uname -U
>>> 1400063
>>>
>>> # uname -K
>>> 1400063
>>>
>>> # pkg upgrade
>>> Updating FreeBSD repository catalogue...
>>> Fetching packagesite.pkg: 100% 5 MiB 4.8MB/s 00:01
>>> Processing entries: 0%
>>> Newer FreeBSD version for package zyre:
>>> To ignore this error set IGNORE_OSVERSION=yes
>>> - package: 1400063
>>> - running kernel: 1400051
>>> Ignore the mismatch and continue? [y/N]:
>>>
>>> Does anyone know why this would happen?
>>> Where does pkg get its notion of the running kernel version?
>>>
>>
>> If I'm reading the sources correctly, it's determining the OS version
>> by looking at the elf headers of various files in this order:
>>
>> getenv("ABI_FILE")
>> /usr/bin/uname
>> /bin/sh
>>
>> So I would assume that `file /usr/bin/uname` shows 1400051 on your
>> system.
>
> Thank you very much! That's it:
> # file /usr/bin/uname
> /usr/bin/uname: ELF 32-bit LSB executable, ARM, EABI5 version 1
> (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1,
> FreeBSD-style, for FreeBSD 14.0 (1400051), stripped
>
>> You can point it to checking another file by setting ABI_FILE[0] in the
>> environment or ignore the check by setting IGNORE_OSVERSION (like
>> advised). The "running kernel:" label seems a bit misleading.
>
> Indeed.
>
> Now the next thing (for me) to research is why the binaries were built
> "for FreeBSD 14.0 (1400051)" when the source tree has 1400063 and uname
> -U also reports 1400063.
> FWIW, this was a cross-build, maybe that played a role too.
If you do a NO_CLEAN=yes build, we don't relink binaries just because
crt*.o changed (where the note is stored).
--
John Baldwin