" Vagy nem linkeli statikusan, hanem "bizik" benne, hogy a libek azok lesznek, mint amivel o letesztelte, illetve hogy nem lesz ABI change, de ez kb. kamikaze."
Vagy esetleg mellekelheti a kerdeses libeket, es csinal egy wrapper scriptet, ami beallitja az LD_LIBRARY_PATH-et, es elinditja a progit. Like VMware. Kb. par evente kell csak a libeket lecserelni, amikor a Glibc-ben ABI valtas tortenik.
"Hogy olyan esztelen hulyesegeket mar ne is emlitsek, hogy pl. bizonyos GNOME/GTK+ userek egesz egyszeruen nem hajlandoak KDE/Qt alkalmazasokat hasznalni (es vice versa)."
Hogy olyan esztelen hulyesegeket mar ne is emlitsek, hogy pl. bizonyos Windows userek egesz egyszeruen nem hajlandok XP-nel ujabb rendszert hasznalni, ahol a .Net 3.5 SP1 utan semmi nincs. VC++ rendszer eseteben meg hatalmas lukak tatonganak az API-ban.
Egyebkent meg a disztro-specifikus tamogatast elsosorban a disztroknak kell megoldani. Van nehany olyan dolog, amit a fejlesztonek, de a tobbsege ezeknek valami GCC-vel osszefuggo marhasag, ami siman elojohet Windows/MSVC viszonylatban is.
Nem akarom bagatellizalni a dolgot, valoban vannak problemak Linuxon, de ma mar messze nem olyan szopas Linuxra fejleszteni, mint regebben. Keretrendszer kerdese az egesz. Azt meg Windowson is jol kell valasztani. Egy Qt app ma mar bele tud annyira simulni egy Gtk kornyezetbe, hogy nem log ki. A KDE appok valoban nem annyira, mert azok mar rengeteg mindent hasznalnak a KDE-bol, ott mas a HIG, maskepp kell az appnak kineznie.
Es az sem veletlen, hogy a jatekok kezdtek elobb jonni a platformra. Hiszen egy jateknal nincs toolkit-harc, a kezelofelulet minden eleme renderelt, nem kell Gtk/Qt/foobar widgetkeszletre tamaszkodni, kicsap egy fullscreen ablakot, es abba azt rajzol, amit akar.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.