Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Dec 2020 16:04:03 +0000
From:      Matthew Seaman <matthew@FreeBSD.org>
To:        LVM <acupuncture@cgocable.ca>, freebsd-questions@freebsd.org
Subject:   Re: 11-STABLE to 12-STABLE Migration Questions
Message-ID:  <3caeac44-7f1b-5ef9-b0c1-4ceffb2048e5@FreeBSD.org>
In-Reply-To: <d3260af6-3d22-448b-8dfc-fefe7e1c754b@cgocable.ca>
References:  <46f7c65c-877c-7910-186e-fcd0879ab205@tundraware.com> <d3260af6-3d22-448b-8dfc-fefe7e1c754b@cgocable.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--v0Wxhc7N2HTA47RioMmIROdIC2OPRMh8V
Content-Type: multipart/mixed; boundary="IbR3PuelgMG88GyzAa7A3pS87tPnNCLqg";
 protected-headers="v1"
From: Matthew Seaman <matthew@FreeBSD.org>
To: LVM <acupuncture@cgocable.ca>, freebsd-questions@freebsd.org
Message-ID: <3caeac44-7f1b-5ef9-b0c1-4ceffb2048e5@FreeBSD.org>
Subject: Re: 11-STABLE to 12-STABLE Migration Questions
References: <46f7c65c-877c-7910-186e-fcd0879ab205@tundraware.com>
 <d3260af6-3d22-448b-8dfc-fefe7e1c754b@cgocable.ca>
In-Reply-To: <d3260af6-3d22-448b-8dfc-fefe7e1c754b@cgocable.ca>

--IbR3PuelgMG88GyzAa7A3pS87tPnNCLqg
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable

On 28/12/2020 14:01, LVM wrote:


> Did just that (with releng). Didn't have to do significant config=20
> changes except manually merging files going through mergemaster -Fi.
>=20
> But I'm using GENERIC for kernel.
>=20
> I certainly didn't have to update my (installed) ports after a svn upda=
te.

Careful now.  There are some pitfalls here that you could run into some=20
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
    have observed.

  * 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
       system libc.so

    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,=20
but you are at risk of problems when you later incrementally upgrade=20
your installed ports.

For absolute peace of mind the simplest course is to force a re-install=20
of all of your ports.  That's overkill really, as many ports don't even=20
contain any compiled binaries, but it's probably quicker overall than=20
sitting down and trying to work out what really has to be reinstalled.

This analysis doesn't apply to loadable kernel modules: those _will_=20
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=20
kernel memory -- lsof(1) being the poster child here.

	Cheers,

	Matthew


--IbR3PuelgMG88GyzAa7A3pS87tPnNCLqg--

--v0Wxhc7N2HTA47RioMmIROdIC2OPRMh8V
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEGfFU7L8RLlBUTj8wAFE/EOCp5OcFAl/qAfQFAwAAAAAACgkQAFE/EOCp5OeA
xg/+JQ3Pkso8EpJfqr7YgE/TMOShMAV1js1+HiI3HFRHQPifbUjCakYYc/L0B5UlR+/7LbyHdQTT
lJY/blamYj+XUEcAxsRCEr9ODC2UwZwrBRToIowRnASVPaMxyalTFVDUCPcqOkItKeb2IN2TMYji
gpdvDxbL21MuXIaXSzusQnIjc+4ZZ15USBQTj/RO3tv8hGDZB+noQu27wD7vOgnnOqj8r9IFVx/u
N9p18SPJN/pj/lvf2rs7lB59OQzzbYQqQtxO0l/XRAH8ns+1VQCHuf7Bj+GqPyBlqA5biNJz0Vnn
+mftVqal6JF1CyO7V0zgF8sHvkp2eVl3HhYZLhPYu5Y9Zeo80AXQWeSDcVRn+9HksoxLpYcU14m0
03visaa3yuPZUz6ZE2u8DWnJSA/oTSoowGzm3mc58+QSSn1eeaKwRRxSgoZXKcA1DuK84zX9ROTO
KtFVbPM8XM5CM8uSgTqsXVFliun6NkgE7TyWYfkV9DSAEJ3w0zm/qh0Lbcwq6XaP+VIy3AaTD3xb
IO3xW+O4bbsoxrHPucLp00Zvc5YVr/Qzs708ow5wnYBWRx1OTaa+Nfu2jDWeA3nq61D3wimhqGUj
HigftfNCxO2JtMvde3hW9jOn3KEc+VtIT+/mIyYQ4K0TnVyp59l4yLPZMvHW3BnzHP23oAocDjXN
4a4=
=zmBG
-----END PGP SIGNATURE-----

--v0Wxhc7N2HTA47RioMmIROdIC2OPRMh8V--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3caeac44-7f1b-5ef9-b0c1-4ceffb2048e5>