shared library pain with 6.0-RELEASE : .so.600 ??
bland at FreeBSD.org
Mon Nov 7 18:02:32 PST 2005
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,
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
More information about the freebsd-ports