Date: Sat, 14 Jan 2012 11:59:40 +0100 From: Henri Hennebert <hlh@restart.be> To: Jeremy Chadwick <freebsd@jdc.parodius.com> Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9 & recompile ports Message-ID: <4F11601C.7030409@restart.be> In-Reply-To: <20120114103741.GA1936@icarus.home.lan> References: <CA%2BdUSyrV_j8GtxS4=yN-DsFCprQ7N%2BEmuRoraDwBLZN1EFFR9w@mail.gmail.com> <CA%2BdUSyqZVVyVkVWTPJXJe921NcZ3RaEN9QojH55NhRNP8xDinA@mail.gmail.com> <4F10009A.7000307@FreeBSD.org> <4F100D9E.80807@FreeBSD.org> <CA%2BdUSyrFVn0skisgeJ1pYjHN3wCXC2tqDPoMoqWNqkjAk8DVmA@mail.gmail.com> <4F10B1AD.9000400@FreeBSD.org> <4F10B6C9.8010607@FreeBSD.org> <4F1140DD.4040300@infracaninophile.co.uk> <4F1158EC.8070803@restart.be> <20120114103741.GA1936@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/14/2012 11:37, Jeremy Chadwick wrote: > On Sat, Jan 14, 2012 at 11:29:00AM +0100, Henri Hennebert wrote: >> On 01/14/2012 09:46, Matthew Seaman wrote: >>> On 13/01/2012 22:57, Andriy Gapon wrote: >>>> But if the appropriate misc/compatX port is installed, then >>>> those libraries do actually exist and the system should be fully >>>> usable... Modulo the compat libraries not working with the new >>>> kernel as Kostik has pointed out. >>> >>> As soon as you update or install an application after this point, >>> you are likely to end up with an application that tries to >>> dynamically link two different versions of the same shlib, and >>> that is a recipe for tears-before-bedtime. >> >> This /etc/libmap.conf help me greatly when I reinstall all my ports -------> ^^^^^^^^^^^^^^^^^^^^^^^^ >> after 9.0-BETA2 and make delete-old-libs: >> >> libsbuf.so.5 libsbuf.so.6 >> libz.so.5 libz.so.6 >> libutil.so.8 libutil.so.9 >> libcam.so.5 libcam.so.6 >> libpcap.so.7 libpcap.so.8 >> libufs.so.5 libufs.so.6 >> libbsnmp.so.5 libbsnmp.so.6 >> libdwarf.so.2 libdwarf.so.3 >> libopie.so.6 libopie.so.7 >> librtld_db.so.1 librtld_db.so.2 >> libtacplus.so.4 libtacplus.so.5 > > This is very, VERY, ***VERY*** dangerous. Apparently nobody has > explained why, so I will: > > When a linked library version number (N of libfoo.so.N) increases or > changes, it indicates there are API/ABI changes to the library. There > is absolutely ZERO guarantee that calling semantics are the same, that > function arguments (thus stack order) are the same, or that structures > used internally by the library are the same. The effects of this can be > devastating -- if you're lucky it'll consist of just "missing symbol", > but it can be a lot worse. The TL;DR version is: there is absolutely > ZERO guarantee that the internal operations and calling semantics of the > libraries are identical. > > Folks reading this thread, PLEASE do not follow the above advice and > leave your system running in that kind of state. Instead of being lazy, I don't want to argue too much, but you don't read me correctly. I just do this during the time I REINSTALL ALL PORTS and then I delete /etc/libmap.conf, of course, I'm not crazy! > rebuild all your ports from scratch or pull down new binary copies > (pkg_add -r ...) for the version of the OS you're running. Doug and I > have the same opinion when it comes to this situation, and it's based > purely on experience. Schedule downtime, spend an afternoon rebuilding > things, whatever -- just do it the Right Way(tm) please. Otherwise > you're creating a lot of support hassle when it comes to trying to > diagnose why some program on your system "behaves oddly" -- weeks go by, > "oh, libmap.conf..." >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F11601C.7030409>