11-STABLE to 12-STABLE Migration Questions
matthew at FreeBSD.org
Mon Dec 28 16:04:09 UTC 2020
On 28/12/2020 14:01, LVM wrote:
> Did just that (with releng). Didn't have to do significant config
> changes except manually merging files going through mergemaster -Fi.
> But I'm using GENERIC for kernel.
> I certainly didn't have to update my (installed) ports after a svn update.
Careful now. There are some pitfalls here that you could run into some
time down the line.
* Most of the shared libraries (certainly all of the important ones) in
the FreeBSD base system use symbol versioning.
Meaning that a binary compiled on an older version of the OS with
shlibs using an older ABI version can still dynamically link against
the latest version of the shlib. Effectively the shlib contains the
entire sequence of ABI versions since they started doing the
versioning thing, which was way back around 7.x-RELEASE IIRC.
So all of your 11.x binaries will still run on a 12.x system, as you
* For simple applications, which only rely on the shlibs from the
FreeBSD base, and don't do any dynamic loading of modules you can
upgrade them at will -- the 'compiled for 12.x' binaries may
reference a more up-to-date ABI version than other ported
applications compiled for 11.x, but there's no chance of conflict
* Any other software with more complex dynamic linking requirements
can be a problem. You may, or may not, find things unexpectedly
crashing when you later do a routine ports update.
The trouble occurs when you end up trying to dynamically link two
different ABI versions from the same shared library into the same
executable. This can happen in a number of ways. For example:
Port A links to a shared library from port B. Both the
application A and the library B need to link against the base
Now, if you install an update to A (links to libc ABI from 12.x) but
not B (still links to libc ABI from 11.x) then you're looking at
this sort of potential version conflict. Same applies if you update
B but not A. It's not a guarranteed failure -- the details of
exactly what symbols A and B reference are important.
The same sort of considerations apply to many perl, python, PHP
etc. modules or to Apache loadable modules.
So, you don't need to reinstall all your ports immediately you upgrade,
but you are at risk of problems when you later incrementally upgrade
your installed ports.
For absolute peace of mind the simplest course is to force a re-install
of all of your ports. That's overkill really, as many ports don't even
contain any compiled binaries, but it's probably quicker overall than
sitting down and trying to work out what really has to be reinstalled.
This analysis doesn't apply to loadable kernel modules: those _will_
have to be upgraded to match the upgraded kernel. Neither does it apply
to certain applications that know "too much" about the internals of the
kernel memory -- lsof(1) being the poster child here.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 840 bytes
Desc: OpenPGP digital signature
More information about the freebsd-questions