Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 09:46:49 GMT:
M>> А в чем смысл брать бинарный билд от старшей версии (КШ9) и M>> пытаться запустить его на младшей(КШ7.3), если под нее есть свой M>> билд?
PE> Я просто прочитал, что он идет на всех системах. И думал, что PE> одного пакета достаточно для любого редхата. А в 7.3 нет линухконфа PE> стандартно. А ставил я сначала на ASP(он там гючит кстати), потом PE> тот же, но без глюков на Шапку9. Я думал, что и на младшей шапке PE> так же будет. Ан нет.
Из сорцов -- пожалуйста, соберется на любых системах (почти любых).
Вообще, странно предполагать совместимость сверху вниз, с каждой версией появляется что-то новое, и считать то, что бинарный билд какого-то пакета, собранный под новую версию, не заработал на более старой, недостатком системы не совсем правильно. Вот если бы пакет от РШ73 не работал на РШ9 притензии еще можно было бы понять.
M>> MS Office можно просто скопировать? А то 2К/XP-тые офисы зачем-то к M>> дистрибу ломятся даже при запуске под новым аккаунтом, не то что M>> после копирования на другой комп. А вот OpenOffice можно.
PE> Возьми пиратский дистрибутив, там все ставится пучком. Копируй куда PE> хошь.
Типа возьми напильник и доработай? Точнее сходи к дядькам-пиратам, они доработали...
PE> А опенофис я смогу с шапки9 на шапку8 или шапку7 скопировать ?
Сможешь, по крайней мере один и тот же билд от ALT Linux Team идет под Slackware 8/9, да и на openoffice.org бинарный билд один на все линуксы и никаких ограничений явно не написано, хотя можно предположить, что на очень старых дистрибах он все таки работать не будет.
Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 09:30:39 GMT:
PE> Как обстоит дело с Линуксом ?
PE> Стандартный набор либ есть, но они имеют разные имена на разные PE> версии например. Мало того, одна и таже либа может в разных PE> дистрибах называться по разному(иногда с дистрибом идет несколько PE> версий либы).
Имеется ввиду версионный суффикс, типа libblabla.so.x.y.z (где x, y, z — некоторые числа)? Так всегда к этому в придачу создаются симлинки с именами libblabla.so.x.y, libblabla.so.x и libblabla.so и если что-то скомпоновано с библиотекой blabla (компоновщику указан ключ -lblabla), то при компоновке и последующих запусках будет искаться только libblabla.so.
Интерфейсы библиотек могут меняться, но это происходит не от релиза к релиза, а довольно редко. Такие изменения могут являться причиной того, что бинарники от древних дистрибутивов, оказываются неработоспособны на последних версиях или наоборот, но так чтобы для каждого дистриба делать свой билд такого нет. Если версии библиотек примерно совпадают, то все будет работать.
M>Интерфейсы библиотек могут меняться, но это происходит не от релиза к релиза, а довольно редко. Такие изменения могут являться причиной того, что бинарники от древних дистрибутивов, оказываются неработоспособны на последних версиях или наоборот, но так чтобы для каждого дистриба делать свой билд такого нет. Если версии библиотек примерно совпадают, то все будет работать.
Это все теория. Я про то самое и сказал.
Но еще момент — ты его упустил — версии эти имеют разные имена файлов и тд. Если совместимость получается после билда, в чем проблема сделать ее без билда ?
Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 12:36:14 GMT:
M>> Интерфейсы библиотек могут меняться, но это происходит не от релиза M>> к релиза, а довольно редко. Такие изменения могут являться причиной M>> того, что бинарники от древних дистрибутивов, оказываются M>> неработоспособны на последних версиях или наоборот, но так чтобы M>> для каждого дистриба делать свой билд такого нет. Если версии M>> библиотек примерно совпадают, то все будет работать.
PE> Это все теория. Я про то самое и сказал. PE> Но еще момент — ты его упустил — версии эти имеют разные имена PE> файлов и тд. Если совместимость получается после билда, в чем PE> проблема сделать ее без билда ?
Что значит версии имеют разные имена?
Если из сорцов можно получить билды под две разные версии, но билд от старой версии не работает с новой, то может просто в сорцах стоит директива условной компиляции типа
#if LIB_VERSION > X.Y
делай так
#elsif
делай сяк
#endif
Можешь привести пример, когда в программе точно нет директив условной компиляции, включающих тот или иной кусок кода в зависимости от версии либы, программа успешно собирается с двумя версиями библиотек, но билд от старой версии не работает с новой?
Здравствуйте, mekanik, Вы писали:
M>Что значит версии имеют разные имена?
Значит то, что значит. Тебе постебаться нужно ?
Я приводил примеры — либы называются по разному !
M>Если из сорцов можно получить билды под две разные версии, но билд от старой версии не работает с новой, то может просто в сорцах стоит директива условной компиляции типа M>#if LIB_VERSION > X.Y M>делай так M>#elsif M>делай сяк M>#endif
Может и так. Не видел исходников.
M>Можешь привести пример, когда в программе точно нет директив условной компиляции, включающих тот или иной кусок кода в зависимости от версии либы, программа успешно собирается с двумя версиями библиотек, но билд от старой версии не работает с новой?
Программа привязывается к либе по имени. От этого и проблемы.
Если тебе не для стеба, я выложу сюда имена этих либ еще раз.
Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 12:57:49 GMT:
M>> Что значит версии имеют разные имена?
PE> Значит то, что значит. Тебе постебаться нужно ? PE> Я приводил примеры — либы называются по разному !
PE> Программа привязывается к либе по имени. От этого и проблемы.
PE> Если тебе не для стеба, я выложу сюда имена этих либ еще раз.
Возможно я что-то пропустил... То есть была либа XYZ версии N и файлик звался libXYZ.so, а в версии (N+1) он стал зваться libABC.so? Если ты имеешь в виду именно это, то для линукса это является таким же исключением, как и для форточек. Если в том дистрибутиве, которым пользуешься ты, это не так и там от релиза к релизу переименовывают все библиотеки, попробуй сменить производителя дистрибутива.
ЗЫ: если ты про libpng12.so и это какая-то версия библиотеки для работы с картинками в формате PNG, а не что-то совершенно другое, то это исключительно замуты RedHat, не надо это обобщать и выдавать за правило для всех производителей дистрибутивов.
Здравствуйте, mekanik, Вы писали:
M>Возможно я что-то пропустил... То есть была либа XYZ версии N и файлик звался libXYZ.so, а в версии (N+1) он стал зваться libABC.so? Если ты имеешь в виду именно это, то для линукса это является таким же исключением, как и для форточек. Если в том дистрибутиве, которым пользуешься ты, это не так и там от релиза к релизу переименовывают все библиотеки, попробуй сменить производителя дистрибутива.
M>ЗЫ: если ты про libpng12.so и это какая-то версия библиотеки для работы с картинками в формате PNG, а не что-то совершенно другое, то это исключительно замуты RedHat, не надо это обобщать и выдавать за правило для всех производителей дистрибутивов.
Это не замуты редхата. Не Редхат пишет Linuxconf. И не только эта либа была не в порядке.
Ты думаешь, что только редхат не придерживается стандартов, а все остаьные его придерживатся ?
Тогда на сайте было бы так — линухконф для
1. редхата 5/6
2. редхата 7
3. редхата 8
4. редхата 9 6. Все остальные линуксы
А там все немного по другому. Есть и мандрейк, сузе, слакваре, калдера и еще кое что.
Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 14:29:03 GMT:
M>> Возможно я что-то пропустил... То есть была либа XYZ версии N и M>> файлик звался libXYZ.so, а в версии (N+1) он стал зваться M>> libABC.so? Если ты имеешь в виду именно это, то для линукса это M>> является таким же исключением, как и для форточек. Если в том M>> дистрибутиве, которым пользуешься ты, это не так и там от релиза к M>> релизу переименовывают все библиотеки, попробуй сменить M>> производителя дистрибутива.
M>> ЗЫ: если ты про libpng12.so и это какая-то версия библиотеки для M>> работы с картинками в формате PNG, а не что-то совершенно другое, M>> то это исключительно замуты RedHat, не надо это обобщать и выдавать M>> за правило для всех производителей дистрибутивов.
PE> Это не замуты редхата. Не Редхат пишет Linuxconf. И не только эта PE> либа была не в порядке. Ты думаешь, что только редхат не PE> придерживается стандартов, а все остаьные его придерживатся ?
Только без PNG library вполне можно жить и по этому в Linux Standard Base (www.linuxbase.org) то, как оно должна называться не оговаривается.
А так вот список стандартных библиотек, который во всех дистрибах должны называться только так и иметь определенный выше названным стандартом интерфейс:
libX11 (libX11.so.6), libXt (libXt.so.6), libGL (libGL.so.1), libXext (libXext.so.6), libICE (libICE.so.6), libSM(libSM.so.6), libdl (libdl.so.2), libcrypt (libcrypt.so.1), libz (libz.so.1), libncurses (libncurses.so.5), libutil (libutil.so.1), libpthread (libpthread.so.0), libpam (libpam.so.0), libgcc_s (libgcc_s.so.1), libm (libm.so.6), libdl (libdl.so.2), libc (libc.so.6), proginterp (/lib/ld-lsb.so.1)
Все что использует только эти либы или статически скомпоновано с библиотеками не из этого списка будет работать на всех LSB-совместимых дистрибутивах. Остальное — может будет, а может и не будет, если с собой либы притащит, то точно будет.
PE> Тогда на сайте было бы так — линухконф для
PE> 1. редхата 5/6 PE> 2. редхата 7 PE> 3. редхата 8 PE> 4. редхата 9 PE> 6. Все остальные линуксы
PE> А там все немного по другому. Есть и мандрейк, сузе, слакваре, PE> калдера и еще кое что.
А может это все не из-за бинарной несовместимости, а из-за разных менеджеров пакетов, используемых в разных дистрибутивах? Тут действительно беспорядок, но вроде ситуация стабилизируется и все постепенно приходят к одному формату, а во всех остальных СОВРЕМЕННЫХ дистрибутивах, для которых RPM4 не является основным форматом пакетов, все равно есть возможность устанавливать пакеты в этом формате.
Здравствуйте, mekanik, Вы писали:
PE>> придерживается стандартов, а все остаьные его придерживатся ?
M>Ну причем тут линуксконф? libpng12.so так обозвали те, кто лепил дистрибутив. M>RedHat, кстати, стандартов придерживается: M>http://www.opengroup.org/lsb/cert/cert_prodlist.tpl
M>Только без PNG library вполне можно жить и по этому в Linux Standard Base (www.linuxbase.org) то, как оно должна называться не оговаривается.
Дело не только в libpng. Были и еще другие либы. Я только первую заромнил.
M>А так вот список стандартных библиотек, который во всех дистрибах должны называться только так и иметь определенный выше названным стандартом интерфейс: M>libX11 (libX11.so.6), libXt (libXt.so.6), libGL (libGL.so.1), libXext (libXext.so.6), libICE (libICE.so.6), libSM(libSM.so.6), libdl (libdl.so.2), libcrypt (libcrypt.so.1), libz (libz.so.1), libncurses (libncurses.so.5), libutil (libutil.so.1), libpthread (libpthread.so.0), libpam (libpam.so.0), libgcc_s (libgcc_s.so.1), libm (libm.so.6), libdl (libdl.so.2), libc (libc.so.6), proginterp (/lib/ld-lsb.so.1)
И это все ? Чем больше либ, тем меньше проблем с распространением.
M>Все что использует только эти либы или статически скомпоновано с библиотеками не из этого списка будет работать на всех LSB-совместимых дистрибутивах. Остальное — может будет, а может и не будет, если с собой либы притащит, то точно будет.
Это понятно. Но толку ?
PE>> Тогда на сайте было бы так — линухконф для
PE>> 1. редхата 5/6 PE>> 2. редхата 7 PE>> 3. редхата 8 PE>> 4. редхата 9 PE>> 6. Все остальные линуксы
PE>> А там все немного по другому. Есть и мандрейк, сузе, слакваре, PE>> калдера и еще кое что.
M>А может это все не из-за бинарной несовместимости, а из-за разных менеджеров пакетов, используемых в разных дистрибутивах? Тут действительно беспорядок, но вроде ситуация стабилизируется и все постепенно приходят к одному формату, а во всех остальных СОВРЕМЕННЫХ дистрибутивах, для которых RPM4 не является основным форматом пакетов, все равно есть возможность устанавливать пакеты в этом формате.
Стабилизируется, это точно. Но пока еще не стабилизировано.
Вот когда на рынках начнут продаваться линуксовые программы отдельно от дистрибов(и инета) повально, тогда будет это что то будет значить.
Здравствуйте, mekanik, Вы писали:
M>Имеется ввиду версионный суффикс, типа libblabla.so.x.y.z (где x, y, z — некоторые числа)? Так всегда к этому в придачу создаются симлинки с именами libblabla.so.x.y, libblabla.so.x и libblabla.so и если что-то скомпоновано с библиотекой blabla (компоновщику указан ключ -lblabla), то при компоновке и последующих запусках будет искаться только libblabla.so.
M>Интерфейсы библиотек могут меняться, но это происходит не от релиза к релиза, а довольно редко. Такие изменения могут являться причиной того, что бинарники от древних дистрибутивов, оказываются неработоспособны на последних версиях или наоборот, но так чтобы для каждого дистриба делать свой билд такого нет. Если версии библиотек примерно совпадают, то все будет работать.
Кстати, я ошибаюсь или как-то при запуске проги можно ей явно некое отображение задать? Т.е если прога слинкована с libblabla, а я ей явно хочу подставить libblabla.1.0.0 (не переделывая симлинк и не пересобирая прогу).
Здравствуйте, WFrag, Вы писали:
M>>Интерфейсы библиотек могут меняться, но это происходит не от релиза к релиза, а довольно редко. Такие изменения могут являться причиной того, что бинарники от древних дистрибутивов, оказываются неработоспособны на последних версиях или наоборот, но так чтобы для каждого дистриба делать свой билд такого нет. Если версии библиотек примерно совпадают, то все будет работать.
WF>Кстати, я ошибаюсь или как-то при запуске проги можно ей явно некое отображение задать? Т.е если прога слинкована с libblabla, а я ей явно хочу подставить libblabla.1.0.0 (не переделывая симлинк и не пересобирая прогу).
Можно симлинк добавить. Я так кой какие депендсы решил. Но не все.
Здравствуйте, mekanik, Вы писали:
M>А может это все не из-за бинарной несовместимости, а из-за разных менеджеров пакетов, используемых в разных дистрибутивах? Тут действительно беспорядок, но вроде ситуация стабилизируется и все постепенно приходят к одному формату, а во всех остальных СОВРЕМЕННЫХ дистрибутивах, для которых RPM4 не является основным форматом пакетов, все равно есть возможность устанавливать пакеты в этом формате.
И к какому формату все стабилизируется? И сколько всего их на сегодняшний день?
Здравствуйте, Plutonia Experiment, Вы писали:
WF>>Кстати, я ошибаюсь или как-то при запуске проги можно ей явно некое отображение задать? Т.е если прога слинкована с libblabla, а я ей явно хочу подставить libblabla.1.0.0 (не переделывая симлинк и не пересобирая прогу).
PE>Можно симлинк добавить. Я так кой какие депендсы решил. Но не все.
Нет, без симлинка. Симлинк уже, допустим, стоит — на версию 2.0.0. Но этой проге явно нужно 1.0.0 подсунуть. Как-то вроде можно было — не пересобирая прогу (по крайней мере с исходников, может просто какой-то тулзой импорты поправить?)
Здравствуйте, mekanik, Вы писали:
M>Plutonia Experiment написал(-а) в Fri, 08 Aug 2003 09:46:49 GMT:
M>>> А в чем смысл брать бинарный билд от старшей версии (КШ9) и M>>> пытаться запустить его на младшей(КШ7.3), если под нее есть свой M>>> билд?
PE>> Я просто прочитал, что он идет на всех системах. И думал, что PE>> одного пакета достаточно для любого редхата. А в 7.3 нет линухконфа PE>> стандартно. А ставил я сначала на ASP(он там гючит кстати), потом PE>> тот же, но без глюков на Шапку9. Я думал, что и на младшей шапке PE>> так же будет. Ан нет.
M>Из сорцов -- пожалуйста, соберется на любых системах (почти любых).
Это я знаю. Про что и речь.
M>Вообще, странно предполагать совместимость сверху вниз, с каждой версией появляется что-то новое, и считать то, что бинарный билд какого-то пакета, собранный под новую версию, не заработал на более старой, недостатком системы не совсем правильно. Вот если бы пакет от РШ73 не работал на РШ9 притензии еще можно было бы понять.
Ты палку не перегибай. Линухконф, например, идет на многих платформах. Только билд нужен для каждой свой.
Вот отсюда и пляши.
M>Сможешь, по крайней мере один и тот же билд от ALT Linux Team идет под Slackware 8/9, да и на openoffice.org бинарный билд один на все линуксы и никаких ограничений явно не написано, хотя можно предположить, что на очень старых дистрибах он все таки работать не будет.
На последних версиях возможно все и идет хорошо. Только подумляю, что это статическая линковкас.
Здравствуйте, AndrewJD, Вы писали:
PE>>Я недавно видел два раз синий экран — запускал утилиты от Sys Internals.
AJD>Утилиты эти случайно не screensaver от Sys Internals ? :)))
Очень смешно, рядовой Шутник ! Этот скринсейвер есть у меня. Но синий экран вылетал после cpumon и tokenmon.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>На последних версиях возможно все и идет хорошо. Только подумляю, что это статическая линковкас.
PE>И это, дядя, сходи сам посмотри и почитай http://www.openoffice.org/dev_docs/instructions.html#linux PE>Загляни в конец страницы.
Офис этот и не только этот обычно входит в состав дистрибов основных. Так что это не очнь хороший пример.
Приведи пример нормальный, и не один, а столько же, сколько и я привел. (Ну или хотя бы половину)
Здравствуйте, Plutonia Experiment, Вы писали:
fAX>>А можно твой вариант? А заодно и ответ, почему 1 из 15 не работает? fAX>>(Да... и так... для размышления... что такое работают? Не падают при запуске? Или тот же note/word-pad держат юникод? Или русский + иврит одновременно? ЧТО ЗНАЧИТ "РАБОТАЮТ"?!!!)
PE>Это значит, что имеют точно такую же функциональность и качество работы на любой системе !
PE>Не работают те, которые привязаны жестко к ядру, например утилиты типа System Internals, Norton Utilities,DiskKeeper начинают работать только с 2000й.
Вообще-то говоря не совсем так. Довольно много функций API появились только начиная с какой-нибудь конкретной версии винды. Например касательно того же иврита+русский, нормальное одновременное отображение левосторонних и правосторонних языков появилось в 2000 (если верить Фень Юаню)... Кроме того, даже если функции существовали во всех версиях виндов, то поведение тоже может различаться — например в GDI когда создаешь кисть заливающую битмапом, в Windows 9x максимальный размер битмапа — 8x8, что может привести к сюрпризам
