Re: pkg does not recognize correct kernel version

On Wed, Feb 28, 2018 at 03:32:43PM -0800, John Baldwin wrote:
> On Wednesday, February 28, 2018 09:45:47 PM Konstantin Belousov wrote:
> > On Wed, Feb 28, 2018 at 10:57:53AM -0800, John Baldwin wrote:
> > > On Tuesday, February 20, 2018 10:19:02 AM Conrad Meyer wrote:
> > > > On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop <ronald-lists_at_klop.ws> wrote:
> > > > > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov
> > > > > <kostikbel_at_gmail.com> wrote:
> > > > >
> > > > >> Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD
> > > > >
> > > > >
> > > > > Which man page? I can't find it in pkg help update or pkg help upgrade or
> > > > > man pkg.
> > > > 
> > > > I had to dig for quite a while to find a reference (pkg.conf(5)):
> > > > 
> > > >      ABI: string      The ABI of the package you want to install.  Default:
> > > >                       derived from the ABI of the /bin/sh binary.
> > > > 
> > > > >> version note:
> > > > >> orion% file /bin/ls
> > > > >> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
> > > > >> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1
> > > > >> (1101506), FreeBSD-style, stripped
> > > > >>
> > > > >> Update world past the __FreeBSD_version which is reported for the
> > > > >> repository.
> > > > >
> > > > >
> > > > > Does this mean I always have to do a *clean* buildworld after every version
> > > > > bump? This takes ages.
> > > > 
> > > > You could also do a -DNO_CLEAN buildworld.
> > > > 
> > > > Or you can continue to override with "-o OSVERSION=foo", although that
> > > > may eventually result in broken packages.  In general the OSVERSION is
> > > > bumped conservatively (more often than will actually result in
> > > > breakage), so you can get away with the easy workaround for a while
> > > > between buildworlds.
> > > 
> > > NO_CLEAN=yes doesn't work.  A clean buildworld is required.  The reason is that
> > > the __FreeBSD_version embedded in binaries is stored in /usr/lib/crt*.o, but
> > > that the dependency rules in lib/csu/Makefile do not rebuild these .o files
> > > everytime <sys/param.h> changes (so a NO_CLEAN=yes buildworld won't rebuild them
> > > leaving them with a stale version).  Furthermore, when binaries and shared
> > > libraries are built, our Makefiles do not specify that the relevant
> > > /usr/lib/crt*.o files are dependencies, so even if we fixed the missing
> > > <sys/param.h> dependency, no binaries would relink to pick up the updated
> > > __FreeBSD_version file unless some other input to the binary changed.  This
> > > one could perhaps be mostly mitigated by forcing libc to depend on the
> > > relevant crt*.o files explicitly (or even having it depend on <sys/param.h>
> > > to force relinking of everything when <sys/param.h> changes).
> > libc already depends on sys/param.h.
> 
> Hmm, even when I removed /usr/obj/usr/src/lib/csu entirely and then did a buildworld
> NO_CLEAN=yes recently /bin/sh was not relinked, though perhaps at that point
> libc already thought it was up-to-date relative to <sys/param.h> from the previous
> build.
> 
> > I think it would be enough to specify that crt1.o depends on sys/param.h
> > as well. Although it is also strange, because e.g. for amd64 the dep
> > thread is csu/amd64/crt1.c->csu/common/crtbrand.c->sys/param.h, which should
> > be detected by the include file calculation.
> 
> I think the detour via assembly + sed is what breaks the dependency chain.
> FWIW, I found that on at least MIPS with clang I did not need the SED_FIX_NOTE
> hack.

Perhaps the FIX_NOTE should be re-evaluated for all the changes happen in
the toolchains since the hack was needed.