3 ms·

A minor nitpick: > These distributions only want one version of the lib, so when an ABI bump is made all the applications that use the lib will be rebuilt and

A minor nitpick: > These distributions only want one version of the lib, so when an ABI bump is made all the applications that use the lib will be rebuilt and have to be updated. This is not true, at least on Archlinux. Currently I have 5 different versions of libpng installed: local/lib32-libpng 1.5.14-1 local/lib32-libpng12 1.2.50-2 local/lib32-libpng14 1.4.11-2 local/libpng 1.5.14-1 local/libpng12 1.2.50-2

Spidler 14y ago
As someone who's been in the distribution business a couple of years ago, I can tell that it isn't as well supported in practice. Imagine for example, a rather classical stack. Let's take KDE cause they are on the top of the news. we have libpng 1.2.x With headers in include/libpng/. ( This is wrong, very acute of you to notice. ) We link kdelibs to libpng-1.2 ( independent use, inherited link ) We link kicker to libpng-1.2 ( kicker uses some things from libpng as well. Yey ) New version of libpng is installed, 1.4. Breaking ABI but not API in the process! If this version is installed in "include/libpng/" You'll link future versions of kicker against this. This gives the chain: kdelibs : libpng 1.2.x kicker : libpng 1.2.x libpng 1.4.x Oh, what just happened? You say that the ABI collides at run-time and nothing loads .png files anymore? So, what if we instead make /include/libpng link to /dev/null, and only explicitly install headers into libpng-1.2 and libpng-1.4? Sure! Lets go that way. kicker now links properly against 1.2 for both. The krita comes along. Krita wants to use a new fancy feature in libpng 1.5. cool. Let's just link that. Wait. did we just collide the public API again? Crap. So, in practice. It doesn't work quite as well as hoped. Function resolving when several libraries provide the same function is. Messy. Especially when they aren't perfectly interchangeable.

Spidler 14y ago

As someone who's been in the distribution business a couple of years ago, I can tell that it isn't as well supported in practice. Imagine for example, a rather classical stack. Let's take KDE cause they are on the top of the news. we have libpng 1.2.x With headers in include/libpng/. ( This is wrong, very acute of you to notice. ) We link kdelibs to libpng-1.2 ( independent use, inherited link ) We link kicker to libpng-1.2 ( kicker uses some things from libpng as well. Yey ) New version of libpng is installed, 1.4. Breaking ABI but not API in the process! If this version is installed in "include/libpng/" You'll link future versions of kicker against this. This gives the chain: kdelibs : libpng 1.2.x kicker : libpng 1.2.x libpng 1.4.x Oh, what just happened? You say that the ABI collides at run-time and nothing loads .png files anymore? So, what if we instead make /include/libpng link to /dev/null, and only explicitly install headers into libpng-1.2 and libpng-1.4? Sure! Lets go that way. kicker now links properly against 1.2 for both. The krita comes along. Krita wants to use a new fancy feature in libpng 1.5. cool. Let's just link that. Wait. did we just collide the public API again? Crap. So, in practice. It doesn't work quite as well as hoped. Function resolving when several libraries provide the same function is. Messy. Especially when they aren't perfectly interchangeable.