pkg does not recognize correct kernel version

[Ronald Klop]

I just did this.

***@sjakie ~]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version:
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!

[***@sjakie ~]# uname -UK
1200058 1200058

[***@sjakie ~]# uname -a
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018
***@sjakie:/data/ronald/obj-freebsd-current/data/ronald/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG
amd64


So uname gives a different version than pkg detects.

What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.

Regards,
Ronald.

[Michael Gmelin]

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o OSVERSION=1200058 helps, but does not feel like the right solution.

What is the output of ‘freebsd-version’?

Best,
Michael

[Ronald Klop]

Post by Michael Gmelin

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
- package: 1200058
- running kernel: 1200056
pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb
18 12:37:36 CET 2018
amd64
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.

What is the output of ‘freebsd-version’?
Best,
Michael

[***@sjakie ~]# freebsd-version
12.0-CURRENT


Regards,
Ronald.

[Rainer Hurling]

Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
Processing entries:   0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018    
amd64
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try

#sysctl kern.osreldate
kern.osreldate: 1200058

HTH,
Rainer Hurling

[Ronald Klop]

Post by Rainer Hurling
Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018
amd64
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try
#sysctl kern.osreldate
kern.osreldate: 1200058
HTH,
Rainer Hurling

[***@sjakie ~]# sysctl kern.osreldate
kern.osreldate: 1200058


Regards,
Ronald.

[Rainer Hurling]

Post by Rainer Hurling

Post by Rainer Hurling
Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
Processing entries:   0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018  
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try
#sysctl kern.osreldate
kern.osreldate: 1200058
HTH,
Rainer Hurling

kern.osreldate: 1200058
Regards,
Ronald.

On my kernel patchlevel 1200058 (r329446) I get:

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.


Perhaps more a local problem :(

[Konstantin Belousov]

Post by Rainer Hurling

Post by Rainer Hurling

Post by Rainer Hurling
Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%    944 B   0.9kB/s    00:01
Fetching packagesite.txz: 100%    6 MiB   6.0MB/s    00:01
Processing entries:   0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb 18
12:37:36 CET 2018  
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try
#sysctl kern.osreldate
kern.osreldate: 1200058
HTH,
Rainer Hurling

kern.osreldate: 1200058
Regards,
Ronald.

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.
Perhaps more a local problem :(

Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD
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.

[Ronald Klop]

On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov

Post by Ronald Klop

Post by Rainer Hurling

Post by Rainer Hurling
Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun

Feb 18

Post by Rainer Hurling

Post by Rainer Hurling

Post by Ronald Klop
12:37:36 CET 2018 >>>
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try
#sysctl kern.osreldate
kern.osreldate: 1200058
HTH,
Rainer Hurling

kern.osreldate: 1200058
Regards,
Ronald.

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.
Perhaps more a local problem :(

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.

Post by Konstantin Belousov
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.

Regards,
Ronald.

[Andreas Nilsson]

I think this was worked around in pkg 1.10.5. As a temporary workaround do
pkg -o OSVERSION=1200058 update -f
pkg upgrade

Best regards
Andreas

Post by Konstantin Belousov

Post by Ronald Klop

Post by Rainer Hurling

Post by Rainer Hurling
Hi Ronald,

Post by Ronald Klop
I just did this.
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 6.0MB/s 00:01
Processing entries: 0%
- package: 1200058
- running kernel: 1200056
FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories!
1200058 1200058
FreeBSD sjakie 12.0-CURRENT FreeBSD 12.0-CURRENT #4 r329516M: Sun Feb

18
-freebsd-current/data/ronald/freebsd-current/amd64.amd64/
sys/GENERIC-NODEBUGamd64

Post by Rainer Hurling

Post by Rainer Hurling

Post by Ronald Klop
So uname gives a different version than pkg detects.
What is happening? pkg update -f gives the same result. -o
OSVERSION=1200058 helps, but does not feel like the right solution.
Regards,
Ronald.

Please try
#sysctl kern.osreldate
kern.osreldate: 1200058
HTH,
Rainer Hurling

kern.osreldate: 1200058
Regards,
Ronald.

#pkg update -f
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100% 944 B 0.9kB/s 00:01
Fetching packagesite.txz: 100% 6 MiB 1.2MB/s 00:05
Processing entries: 100%
FreeBSD repository update completed. 28645 packages processed.
All repositories are up to date.
Perhaps more a local problem :(

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.

Post by Konstantin Belousov
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.

Regards,
Ronald.

_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-***@freebsd.org"

[Trond Endrestøl]

Post by Andreas Nilsson
Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

[Ronald Klop]

On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl

Post by Trond Endrestøl

Post by Andreas Nilsson
Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

pkg: Newer FreeBSD version for package gnome-menus:
- package: 1200058
- running kernel: 1200056

So it says "running kernel", but it actually checked "version of
FreeBSD_version while building /bin/sh" or something like that.
This sounds over-engineered and (more important) confusing.

Ronald.

[Trond Endrestøl]

Post by Ronald Klop
On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl

Post by Trond Endrestøl

Post by Andreas Nilsson
Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

- package: 1200058
- running kernel: 1200056
So it says "running kernel", but it actually checked "version of
FreeBSD_version while building /bin/sh" or something like that.
This sounds over-engineered and (more important) confusing.

I tried the simply approach of running "make clean; make build" in
/usr/src/bin/sh, hoping it would generate binaries with the correct
osversion in the .note.tag section. Boy, I couldn't be more wrong.
Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever
osversion is increased. I'm probably missing a simpler step.

[Andreas Nilsson]

As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
easier to deal with.

Best regards
Andreas

On Feb 21, 2018 20:45, "Trond Endrestøl" <

Post by Trond Endrestøl

Post by Ronald Klop
On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl

Post by Trond Endrestøl

Post by Andreas Nilsson
Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

- package: 1200058
- running kernel: 1200056
So it says "running kernel", but it actually checked "version of
FreeBSD_version while building /bin/sh" or something like that.
This sounds over-engineered and (more important) confusing.

I tried the simply approach of running "make clean; make build" in
/usr/src/bin/sh, hoping it would generate binaries with the correct
osversion in the .note.tag section. Boy, I couldn't be more wrong.
Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever
osversion is increased. I'm probably missing a simpler step.
--
Trond.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Michael Gmelin]

Still breaks automation, doesn’t it?

Post by Andreas Nilsson
As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
easier to deal with.
Best regards
Andreas
On Feb 21, 2018 20:45, "Trond Endrestøl" <

Post by Trond Endrestøl

Post by Ronald Klop
On Tue, 20 Feb 2018 11:30:52 +0100, Trond Endrestøl

Post by Trond Endrestøl

Post by Andreas Nilsson
Does this mean I always have to do a *clean* buildworld after every version
bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in
sys/sys/param.h is incremented, then it's time to blow away /usr/obj,
recreate everything to ensure the correct value of osversion in the
.note.tag section of each executable, and reinstall base prior to
updating localbase. See PR 225104 for more details,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

- package: 1200058
- running kernel: 1200056
So it says "running kernel", but it actually checked "version of
FreeBSD_version while building /bin/sh" or something like that.
This sounds over-engineered and (more important) confusing.

I tried the simply approach of running "make clean; make build" in
/usr/src/bin/sh, hoping it would generate binaries with the correct
osversion in the .note.tag section. Boy, I couldn't be more wrong.
Hence my (possibly wrongful) conclusion of wiping /usr/obj whenever
osversion is increased. I'm probably missing a simpler step.
--
Trond.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[Trond Endrestøl]

Post by Andreas Nilsson
As of pkg-1.10.5 it will ask if you wish to proceed which makes this much
easier to deal with.

That's an huge improvement. sys/sys/param.h and base are in agreement
on the systems I manage, so I won't see the improvement in action for
some time.

[Conrad Meyer]

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

Post by Ronald Klop

Post by Konstantin Belousov
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.

Best,
Conrad

[John Baldwin]

Post by Conrad Meyer

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

derived from the ABI of the /bin/sh binary.

Post by Ronald Klop

Post by Konstantin Belousov
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).

This matters for more than just pkg as the kernel also looks at the embedded
__FreeBSD_version in binaries to make decisions about compat shims to enable
(grep for P_OSREL in sys/).

[Konstantin Belousov]

Post by John Baldwin

Post by Conrad Meyer

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

derived from the ABI of the /bin/sh binary.

Post by Ronald Klop

Post by Konstantin Belousov
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.

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.

Post by John Baldwin
This matters for more than just pkg as the kernel also looks at the embedded
__FreeBSD_version in binaries to make decisions about compat shims to enable
(grep for P_OSREL in sys/).
--
John Baldwin
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current

[John Baldwin]

Post by Konstantin Belousov

Post by John Baldwin

Post by Conrad Meyer

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

derived from the ABI of the /bin/sh binary.

Post by Ronald Klop

Post by Konstantin Belousov
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.

Post by Konstantin Belousov
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.

[Konstantin Belousov]

Post by John Baldwin

Post by Konstantin Belousov

Post by John Baldwin

Post by Conrad Meyer

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

derived from the ABI of the /bin/sh binary.

Post by Ronald Klop

Post by Konstantin Belousov
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.

Post by Konstantin Belousov
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.

[John Baldwin]

Post by Konstantin Belousov

Post by John Baldwin

Post by Konstantin Belousov

Post by John Baldwin

Post by Conrad Meyer

Post by Ronald Klop
On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov

Post by Konstantin Belousov
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.

derived from the ABI of the /bin/sh binary.

Post by Ronald Klop

Post by Konstantin Belousov
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.

Post by Konstantin Belousov
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.

I believe modern GCC still needs the hack unfortunately. :(