Свежие комментарии
| Title | Comment |
|---|---|
| Это не совсем то, dll hell получается не в процессе разработ |
Это не совсем то, dll hell получается не в процессе разработки, а в процессе эксплуатации написанного. Когда у тебя чудесным образом меняется поведение программы из-за подмены библиотеки. А то, что есть проблемы в момент разработки это несколько иное. То, что у юзера окружение будет совпадать с тем в котором отлаживал разработчик как-раз залог нормальной работы. А требовать со всех супер качественного кода в каждой новой версии, чтобы все старое работало с новым без проблем - вот это утопия и залог проблем. Собственно этого как я понял все-таки нет, можно разные версии библиотек и в unix процессах смешивать (натолкнулся на упоминание про это где-то), только вот для стандартной библиотеки видимо решили поступить иначе. |
| Почему нельзя - понятно даже очень. Это же DLL hell, но не н |
Почему нельзя - понятно даже очень. Это же DLL hell, но не на этапе линковки, а на рантайме. То самое против чего я возмущался - две free() в одном процессе. |
| Ошибку то пофиксили, а вот программа может работать только с |
Ошибку то пофиксили, а вот программа может работать только с ошибочной версией библиотеки. Попросить разработчика поправить это конечно здорово но не всегда возможно. Вобщем можно очень стараться и подменять старые функции новыми вариантами, но может наступить момент, когда поведение в какой-то детали изменится и это поломает давно работающий код, вот тогда и придется как-то решать эту проблему. Если в unix есть поддержка версионирования dll в принципе, то чем тогда лучше glibc, почему нельзя несколько версий подгрузить одновременно? |
| Да, в пределах одного major все нормально, берем старшую вер |
Да, в пределах одного major все нормально, берем старшую версию и все. Вот если есть два бинарных модуля, требующие разные major - то все, приплыли, нет возможности это запустить без перекомпиляции одного из них. Что касается ошибок, то ну нельзя сказать, что в libc их нет, но в этом мире принято пофиксить ошибку (и вернуть патч разработчику, например), а не обойти. |
| Т.е. если я использую модуль использующий новую версию glibc |
Т.е. если я использую модуль использующий новую версию glibc, то буду вынужден тоже ее использовать иначе просто не будет линковаться. Как я понял два разных glibc не могут быть загружены в одном процессе. Если это делается на уровне линковки и как-то вшито в модуль, то как быть если я пытаюсь пристыковать два чужих модуля каждый из которых был слинкован с какой-то своей версией. Я должен взять самую старшую за основу и как-то переопределить из зависимость, правильно я понимаю? Принцип - подключай самый новый вариант и все заработает неплох, пока существует только одна библиотека. Есть правда чисто техническая проблема - им надо тщательно воспроизводить свои старые ошибки. |
| Добавили, естественно. Но если кто-то требует новое, его не |
Добавили, естественно. Но если кто-то требует новое, его нету (и версионирование не сработало, скажем) - то просто не слинкуется. А за совместимостью ABI должны следить. |
| Понятно. А с glibc как-бы гарантируют что подобного не произ |
Понятно. А с glibc как-бы гарантируют что подобного не произойдет. Т.е. они туда ни одной новой функции не добавили и все тотально взаимозаменяемо? |
| Тут надо отделить. Версионность четко отрабатывает, каждому |
Тут надо отделить. Версионность четко отрабатывает, каждому модулю свое, а вот обеспечить чтобы у всех был один и тот-же модуль - такого нет. Кстати подобная проверка в линкере полезна. Иногда полезно разкрыть граф зависимостей и просмотреть кто кого тянет. В windows - это утилита depends или dumbbin с консоли. Кстати если чего не хватает depends покажет. |
| Судя по размеру winsxs у тебя многое из этого нужно, у меня |
Судя по размеру winsxs у тебя многое из этого нужно, у меня то меньше почти в два раза. Наверное при деинсталляции оттуда может что-то убираться. |
| Вопрос был бы своевременным, если бы альтернативные библиоте |
Вопрос был бы своевременным, если бы альтернативные библиотеки действительно были бы. Я гуглением нашел только упоминания glibc для солярки (и то, это скорее пожелания, чем что-то еще). Но если возникнут - они вынужденно будут совместимы по ABI, иначе пользоваться никто не будет (а одному автору такой проект не потянуть). Т.е. вся альтернативность сейчас - это glibc 2.6 против версии 2.2 |
| Тут я могу точно сообщить - версия crt менялась с выпуском v |
Тут я могу точно сообщить - версия crt менялась с выпуском vs2005 sp1, название файла не менялось и с выпуском vs2008 sp1. Название меняется при смене версии vs, они прибавляют 1. Если нет такой библиотеки, то _ничего_ работать не будет, манифест внедренный в dll/exe четко это оговаривает. Дебажные версии поставляются всегда отличаются - там даже название файла другое (d в конце). Т.е. все жестко - имя и версия должны совпадать. Насчет многопоточности не помню, там вроде mt в названии есть. |
| Многопоточность - это еще одна сторона одной проблемы - согл |
Многопоточность - это еще одна сторона одной проблемы - согласование разных версий. В .net для этого есть атрибуты которые помечают реентерабелен ли метод или класс, т.е. наверное уже компилятор что-то может диагностировать, аналогично наверное с системными библиотеками в .net. А если говорить про однопоточную версию crt, то сейчас ей я думаю уже мало кто пользуется, падение производительности совсем небольшое, поэтому лучше не мудрить. |
| Жалко будет. Потому что Linux совсем опопсел. А BSD я не лю |
Жалко будет. Потому что Linux совсем опопсел. А BSD я не люблю почему-то. |
| Хорошо, версионирование есть (пусть и между major версиями), |
Хорошо, версионирование есть (пусть и между major версиями), теперь вопрос почему не может быть двух версий в пределах одного процесса, как быть если один модуль хочет одну версию, а другой другую? |
| Все-же мне не очень понятна например такая ситуация. Один пр |
Все-же мне не очень понятна например такая ситуация. Один проект использует glibc, а другой например dietlibc, как они будут уживаться? Если предположить что есть системный сервис управления памятью, то допустим все через него работают, а как быть с FILE*, где гарантия что автор одной библиотеки не изменит эту структуру под себя. Опять-же есть ли там debug/release различия для одной и той же библиотеки? |
| Ну уж обновление рантайма от Microsoft сама Microsoft могла |
Ну уж обновление рантайма от Microsoft сама Microsoft могла бы и класть, тоже мне проблема. С 7-гигабайтным (у меня) winxs я понял что меня раздражает - нет способа узнать, что из 20 версий примерно одного и того же - 15 уже не нужны никому. |
| А я вот не уверен, кстати. Если такие есть (не считая, скаж |
А я вот не уверен, кстати. Если такие есть (не считая, скажем, зоопарка внутри одной системы - с тредами такими, с тредами сякими, отладочные) - они скорее всего будут бинарно совместимы. |
| И с выкрутасами от Оракла - имеет шанс умереть молодым, без |
И с выкрутасами от Оракла - имеет шанс умереть молодым, без 64-битного time_t. |
| Ну да, естественно, есть много разницы. Но у вас приложение |
Ну да, естественно, есть много разницы. Но у вас приложение - или однопоточное или много. Если оно много, а где-то внутри какого-то DLL завется однопоточный - это тоже превед приключениям (не говоря о том, что уж много или одно-поточный можно разбираться на рантайме внутри одного аллокатора). С отладкой - да, теоретически приятно иметь отладочный аллокатор только для своего кода, а скажем для системного - не иметь. Но готов этим пожертвовать. |
| В солярке, что характерно, как в 8-ке была libc.so.1, так и |
В солярке, что характерно, как в 8-ке была libc.so.1, так и в десятке libc.so.1. |
| Согласен удобно, но вот crt в windows меняется с версией vis |
Согласен удобно, но вот crt в windows меняется с версией visual studio или vs service pack, кто-то должен положить это обновление в систему. А потом как я понял есть альтернативные crt для unix и он уж наверняка идут просто в комплекте с софтом. |
| >Просто механизм динамической линковки другой - тот же free( |
>Просто механизм динамической линковки другой - тот же free() в рамках процесса будет один Ну вот тут видимо принципиальная разница с windows - там аллокаторы в crt разные, дебажная версия имеет другой заголовок блока и вообще работает несколько иначе. Потом существует многопоточная и однопоточная реализациия аллокатора, многопоточный чуть медленнее работает, там критические секции есть. |
| Я солярку лет 10 уже не встречал, но и там должно бы быть, к |
Я солярку лет 10 уже не встречал, но и там должно бы быть, как без него. В Linux и FreeBSD - есть. В Макоси - судя по номерам версии в именах библиотек - тоже есть. Но если я правильно помню, версионирование ELF-библиотек идет по major версии (в soname нету minor), т.е. если апгрейд был c сохранением major, то даже если старую версию не снести, ее считай что и нету, динамический линковщик не найдет. |
| Понятно, но значит все-таки связывание идет с конкретной реа |
Понятно, но значит все-таки связывание идет с конкретной реализацией. |
| Ну вот у меня то с чего мой вопль начался - собралося ведь. |
Ну вот у меня то с чего мой вопль начался - собралося ведь. Взяло и собралось. И из десятка примеров не работал только один. А этого не должно было бы вовсе быть, должно было где-то заругаться. |
| Понимаете, практика на Unix-системах, уж всяко в смысле CRT |
Понимаете, практика на Unix-системах, уж всяко в смысле CRT не менее развесистых, очень простая: берешь варез в бинарниках, никакой libc/CRT в поставке нет - и он работает. |
| alex пишет, что в unix есть версионирование DLL/.SO, поэтому |
alex пишет, что в unix есть версионирование DLL/.SO, поэтому вполне возможно, что версии то разные реально работают, либо они осознанно остались на старой. |
| Если FILE* вернет, то нельзя - это объект CRT, т.е. он управ |
Если FILE* вернет, то нельзя - это объект CRT, т.е. он управляется библиотекой. Если системный handle - то можно, хэндлы иногда можно и между процессами передавать. |
| В windows winsxs тоже дает возможность оверрайдить версии, н |
В windows winsxs тоже дает возможность оверрайдить версии, но это конечно может плохо кончиться. |
| Если интерфейс простой и фиксированный, то действительно его |
Если интерфейс простой и фиксированный, то действительно его можно не менять. Например как API самой системы, хотя и там бывают проблемы. Если же есть какое-то изменение, то ошибки и особенности неизбежны, писать без ошибок пока никто не научился. С crt ситуация такова, то к сожалению это не только стандартная библиотека C. Наверное часть его можно и заморозить, но это видимо и делать неудобно и возможно не решило бы проблему, т.к. используются не только стандартные функции, вот цитирую wikipeda: http://ru.wikipedia.org/wiki/Libc >Стандартная библиотека языка Си только регламентирует наличие >вышеупомянутых подпрограмм и их поведение. Так как реализация >компилятора может зависеть от наличия этих дополнительных >функций, то все зависит от того, какие подпрограммы собраны в >Стандартную библиотеку языка Си, таким образом любая программа, >разработанная с их помощью, будет нуждаться в них. >Хотя часто путают их со Стандартной библиотекой языка Си из-за их >комплектации, библиотека CRT не является стандартизированной >частью языка и зависит от особенностей поставки программного >продукта. С MS-DOS скорее всего старались написанное не трогать, только добавлять новое. В win32 уже не все так просто, ядро они дорабатывали и что-то все-же менялось, находили баги, для совместимости со старым у них есть хитрая подсистема которая имитирует ошибочное или считающиеся нестандартным поведение для многих старых программ. |
Pages
