In the last days, I entered the magic, wicked world of libtool patches collection.. this because I want to give to Gentoo/FreeBSD a simpler way to update their system without breaking binary compatibility with every single update of glib, gtk and so on.
Let’s start from the start: one of the problems on Gentoo/FreeBSD respect Gentoo/Linux is that libtool usually creates library with a single version info. This makes so that also a single release can change SONAME and break binary compatibility. This is the case for example of libiconv.. 1.10 release would have broke compatibility with 1.9 if I wasn’t going to do something, and that would have meant breaking gcc, as it links to libiconv.
My solution was hacking at libtool and tell it to use Linux-way to create libraries, using three version information values… so that libiconv-1.9 would install libiconv.so.2.2 and 1.10 libiconv.so.2.3, not breaking binary compatibility (SONAME remains libiconv.so.2).
This works not only with libiconv but with many other major libraries such as glib and gtk.
This is still experimental, as I don’t really know why FreeBSD used the .so.X way to create libraries, but seems to work till now. We’ll can only say trying that.
Now, the problem is that not every ebuild right now calls elibtoolize, and we’ll probably need to add it to some packages if they change often the SONAME right now, but maybe Martin will implement soon the elibtoolize-in-econf so that we can make use of that without having to call it directly.
Oh another little drawback actually. I was able to create patches for the most common libtool versions, but it’s possible that some package uses a strange version of libtool where the fbsd-conf patch doesn’t apply clean. In such a case, elibtoolize is told to kill the process. Please report elibtoolize failures on Bugzilla (in product Gentoo/FreeBSD) so that I can fix them.
Little note: I’m happy to see that an x86 arch team is being formed, this really is good news to me as I can finally get rid of x86-specific problems in xine and let x86 team handle them… as I don’t know how to fix them at all!
