shared library pain with 6.0-RELEASE : .so.600 ??

[Alexander Nedotsukov]

Joe,

First. .600 have nothing in common with FreeBSD release-tag. Those 
numbers belong to GNOME/GTK libraries release cycle. Second. Basically 
multiple library versions co-existence is not so rosy as you probably 
think. Even if you solve header files conflicts there are a lot of 
software which alloc/dealloc various kind of resources across modules, 
libraries which  extensively use static data etc. etc. etc. This will 
lead to very weird run-time behavior.
But on the good note I'd happy to tell that those frequent shared 
library bumps was due bug in GNU autohell tools used by GNOME/GTK 
software authors. This problem addressed in GNOME 2.12 FreeBSD port 
which just hit the repository. So this is a last time you required to 
step through massive rebuild w/o a good reason for that.

All the best,
Alexander.

Joe Rhett wrote:
> Out of curiosity, why does 6.0-RELEASE ship with packages that install
> shared libraries with .so.600 version numbers?
>
> It appears that installing nearly any port requires that all these
> libraries get rebuild and reinstalled, followed by manually creating
> symlinks to the .so.600 versions that everything is linked against.
>
> 1. Shouldn't library ports allow multiple versions to be installed, rather
> than forcing a deinstall?  libIDL is the most common dependancy culprit,
> and with 5.x we ended up with 3 different symbolic links to make everything
> happy. (unmaintainable, manually hacked into place symbolic links which
> work around problems in the packages database)
>
> 2. Why did 6.0-RELEASE (and I think other releases in the past too?) name
> the shared libraries with a release-tag version?  Is there some logic to
> this that escapes me?  It only strikes me as painful for all the obvious
> reasons.
>
>