FreeBSD 9 & recompile ports

[Henri Hennebert]

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..."
>