История изменений

Почитал через Google Translate. Линус говорит о том, что пользовательские приложения со всеми версиями ядра работают одинаково. Но Мигель говорил о другом - что приложения используют десятки системных библиотек из /usr/lib, которые постоянно меняют свои API и, следовательно, название файла с libcurl.so.3 на libcurl.so.4. Это список зависимостей Wine:

libX11.so.6
libXext.so.6
libfreetype.so.6
libfontconfig.so.1
libGL.so.1
libGLU.so.1
libXrender.so.1
libXinerama.so.1
libXxf86vm.so.1
libXi.so.6
libXrandr.so.2
liblcms.so.1
libpng12.so.0
libcrypto.so.0.9.8
libssl.so.0.9.8
libxml2.so.2
libjpeg.so.62
libXcomposite.so.1
libcups.so.2
libXcursor.so.1
libdbus-1.so.3
libhal.so.1
libsane.so.1
libgphoto2.so.2
libgphoto2_port.so.0
libldap-2.4.so.2
libldap_r-2.4.so.2
liblber-2.4.so.2
libxslt.so.1
libcapi20.so.3
libjack.so.0
libodbc.so.1
libgnutls.so.26

Если одна библиотека переименовалась, программа не запустится! И бинарные пакеты от одной версии дистрибутива несовместимы с другой версией того же дистрибутива и другим дистрибутивом. Нужно пересобирать из SRPM. Явление общеизвестное, и в нём неудовольсвие Мигеля Де Икасы.

Есть много способов обойти проблему, например статическая линковка - а если в библиотеке сетевая уязвимость? Тогда она останется в программе навечно. Или положить все библиотеки в архив с программой. Ладно, но появляется проблема с тем, что программы от GCC 4.7 несовместимы с GCC 4.5, и желательно всё коммерческое компилировать с GCC 4.1. Можно конечно и здесь положить библиотеки libgcc и libstdc++, но для некоторых программ их размер может превысить размер всей остальной программы (utorrent, pcsx2).

Все эти проблемы решаемы. Но о них нигде не говорятся явно, вот и натыкаемся на незапускающиеся программы. Если Linux станет популярнее, то эти тонкости будут на слуху и все будут компилировать пакеты грамотнее. Таково моё мнение.

Почитал через Google Translate. Линус говорит о том, что пользовательские приложения со всеми версиями ядра работают одинаково. Но Мигель говорил о другом - что приложения используют десятки системных библиотек из /usr/lib, которые постоянно меняют свои API и, следовательно, название файла с libcurl.so.3 на libcurl.so.4. Это список зависимостей Wine:

libX11.so.6
libXext.so.6
libfreetype.so.6
libfontconfig.so.1
libGL.so.1
libGLU.so.1
libXrender.so.1
libXinerama.so.1
libXxf86vm.so.1
libXi.so.6
libXrandr.so.2
liblcms.so.1
libpng12.so.0
libcrypto.so.0.9.8
libssl.so.0.9.8
libxml2.so.2
libjpeg.so.62
libXcomposite.so.1
libcups.so.2
libXcursor.so.1
libdbus-1.so.3
libhal.so.1
libsane.so.1
libgphoto2.so.2
libgphoto2_port.so.0
libldap-2.4.so.2
libldap_r-2.4.so.2
liblber-2.4.so.2
libxslt.so.1
libcapi20.so.3
libjack.so.0
libodbc.so.1
libgnutls.so.26

Если одна библиотека переименовалась, программа не запустится! И бинарные пакеты от одной версии дистрибутива несовместимы с другой версией того же дистрибутива и другим дистрибутивом. Нужно пересобирать из SRPM. Явление общеизвестное, и в нём неудовольсвие Мигеля Де Икасы.

Есть много способов обойти проблему, например статическая линковка - а если в библиотеке сетевая уязвимость? Тогда она останется в программе навечно. Или положить все библиотеки в архив с программой. Ладно, но появляется проблема с тем, что программы от GCC 4.7 несовместимы с GCC 4.5, и желательно всё коммерческое компилировать с GCC 4.1. Можно конечно и здесь положить библиотеки libgcc и libstdc++, но для некоторых программ их размер может превысить размер всей остальной программы.

Все эти проблемы решаемы. Но о них нигде не говорятся явно, вот и натыкаемся на незапускающиеся программы. Если Linux станет популярнее, то эти тонкости будут на слуху и все будут компилировать пакеты грамотнее. Таково моё мнение.

Почитал через Google Translate. Линус говорит о том, что пользовательские приложения со всеми версиями ядра работают одинаково. Но Мигель говорил о другом - что приложения используют десятки системных библиотек из /usr/lib, которые постоянно меняют свои API и следовательно, название файла с libcurl.so.3 на libcurl.so.4. Это список зависимостей Wine:

libX11.so.6
libXext.so.6
libfreetype.so.6
libfontconfig.so.1
libGL.so.1
libGLU.so.1
libXrender.so.1
libXinerama.so.1
libXxf86vm.so.1
libXi.so.6
libXrandr.so.2
liblcms.so.1
libpng12.so.0
libcrypto.so.0.9.8
libssl.so.0.9.8
libxml2.so.2
libjpeg.so.62
libXcomposite.so.1
libcups.so.2
libXcursor.so.1
libdbus-1.so.3
libhal.so.1
libsane.so.1
libgphoto2.so.2
libgphoto2_port.so.0
libldap-2.4.so.2
libldap_r-2.4.so.2
liblber-2.4.so.2
libxslt.so.1
libcapi20.so.3
libjack.so.0
libodbc.so.1
libgnutls.so.26

Если одна библиотека переименовалась - и всё, программа не запустится! И бинарные пакеты от одной версии дистрибутива несовместимы с другой версией того же дистрибутива и другим дистрибутивом. Нужно пересобирать из SRPM. Явление общеизвестное, и в нём неудовольсвие Мигеля Де Икасы.

Есть много способов обойти проблему, например статическая линковка - а если в библиотеке сетевая уязвимость? Тогда она останется в программе навечно. Или положить все библиотеки в архив с программой. Ладно, но появляется проблема с тем, что программы от GCC 4.7 несовместимы с GCC 4.5, и желательно всё коммерческое компилировать с GCC 4.1. Можно конечно и здесь положить библиотеки libgcc и libstdc++, но для некоторых программ их размер может превысить размер всей остальной программы.

Все эти проблемы решаемы. Но о них нигде не говорятся явно, вот и натыкаемся на незапускающиеся программы. Если Linux станет популярнее, то эти тонкости будут на слуху и все будут компилировать пакеты грамотнее. Таково моё мнение.