...может задолбать небольшого слона....
Все-таки я продолжаю считать, что кавардак с многочисленными несовместимыми рантаймами не украшает Microsoft Windows вообще и MSVC в частности.
Ситуация:
- Свежий Qt 4.7.2, собранный (в Нокии) MSVC 2008
- Мой варез, который я собираю лично MSVC 2010
- В целом варез работает.
- В частностях валится с грохотом, где-то в недрах (отладчик, впрочем, говорит что Heap Corrupted т.е. эти недра - опять аллокаторы).
Собственно, причины этого мы давно обсудили, но хочется этого место еще попинать.
Работает вся простая функциональность. Создал объект, удалил объект, все такое.
Валится вот такое вот по смыслу место:
void SomeTableView::selectionChanged (const QItemSelection & selected, const QItemSelection & deselected )
{
QTableView::selectionChanged(selected,deselected);
QModelIndexList items = selected.indexes();
....
QModelIndexList - это QList этих самых QModelIndex.
То есть этот самый selected.indexes() у себя аллоцирует нечто в одной копии инстационированного QList, а у меня *это* потом пытается освободиться. И приехали.
Соответственно, обойти это дело в духе "кто породил, тот и убивает" - уже никак невозможно.
Я собственно к чему клоню: не должно быть у процесса нескольких версий одного рантайма. То бишь, DLL и EXE вправе ссылаться на разные версии, в этих версиях должна быть грамотно написана совместимость ("одинаковый major - совместимо"), если требуются разные major - сразу послать нахрен, а если разные minor - то подобрать рантайм с minor-версией не ниже затребованной. И, естественно, более высокий minor означает совместимость со всем что ниже.
<holywar>ну, примерно как в Linux сделано</holywar>
Потому что ситуация "немножко работает, но вообще может и упасть" (а падает у меня оно в месте, до которого не всякий юзер доберется) - категорически неприемлема.
P.S. А пишу я вам это, потому как пересобираю Qt и часика два мне нечем себя занять....
P.P.S. Как в таком мире можно поставлять какие-то DLL-ки в бинарном виде (ну, там, библиотеки за деньги) я просто не понимаю. Под каждый рантайм, по четыре версии (/MT /MTd /MD /MDd) ?
Comments
Ссылка ведёт в 404 (в хвост залез тег)
Ссылка ведёт в 404 (в хвост залез тег)
поправил, спасибо
поправил, спасибо
> не должно быть у процесса
> не должно быть у процесса нескольких версий одного рантайма
дадада. И в Linux, при залезании в проприетарщину и прочий эфффективный менеджмент, на это можно напороться и легко огрести примерно того же.
"Примерно того же" - это две
"Примерно того же" - это две версии libc в одном процессе? Как-то удивительно.
Вот с чем я сталкивался, это когда две *разные* библиотеки реализуют одинаковые вызовы. Конкретно в нашем случае это были libstdc++ и STLport. Это тоже был секс, конечно.
Конкретно были две версии
Конкретно были две версии openssl, возможно даже одной версии. Одна статическая (в ряде мест), вторая .so
Я вижу единственный способ
Я вижу единственный способ этого добиться не предпринимая специальных усилий:
- есть .so, которая зависит от динамической libopenssl.so
- а приложение линкуется статически.
Все другие способы предполагают запихивание статической openssl внутрь какой-то .so с экспортом символов. По смыслу это мало отличается от двух разных STL с одинаковыми именами функций, но требует специальных усилий для изготовления.
Там были специальные усилия.
Там были специальные усилия. Я ж говорю: проприетарщина и эффективный менеджмент.
> - есть .so, которая зависит
> - есть .so, которая зависит от динамической libopenssl.so
> - а приложение линкуется статически
Но да, afair так и получилось. Причём libtool был упорен и хотел непременно впихнуть динамическую версию. в конце концов пришлось сесть и его попатчить. Я, помню, в ходе патченья реализовал ассоциативные массивы на шелле.
Ну, кстати, в моей практике
Ну, кстати, в моей практике (Спамтест) тоже что-то такое было. Мы не libopenssl впихивали, но тоже что-то подобное, то ли резолвер, хрен упомнит.
В те годы в Линуксе бывало весело, поэтому наша задача была - получить бинарник, зависящий только от libc (его делать статиком в линуксе вредно) а все остальное всосать статикой.
Ну и в такой постановке это ничему не противоречит, кстати, потому что libc ни от чего не зависит сам, а следовательно его динамически линковать можно безопасно.
> <holywar>ну, примерно как в Linux сделано</holywar> Да!
> ну, примерно как в Linux сделано
Да! Да! Да!
Сколько людей наступает на грабли с этими релиз/дебаг либами!
Я наступил на граблю дебаг/дебаг. Компилятор одного производ
Я наступил на граблю дебаг/дебаг. Компилятор одного производителя.
Начинаю сильно удивляться, как мир до сих пор не рухнул.
<blockquote>Под каждый рантайм, по четыре версии (/MT /MTd /
Похоже на то.
По крайней мере предсобранный в boostpro.com буст так и поставляется (точнее, поставляются только релизные версии под разные рантаймы). Да и другие либы вроде так же...
Такие вот жопа-кеды... Надо бы как-то более реально МС попинать, но это такой неповоротливый монстр, что как это сделать - я х.з. До сих пор СП1 для 10-студии сделать не могут...
Не, дебажные версии тоже. 4 компилятора x 8 версий: <img src
А, точно, точно) Уже давно ставил и как-то тут понадобилось
А, точно, точно) Уже давно ставил и как-то тут понадобилось дебажить, а либ не нашёл, пришлось вручную собирать. Кстати, хотя меня это как заправского виндузятника малость пугало по началу, оказалось, что всё неплохо собираеццо и предсобранные версии особо и не нужны (особенно вспоминая, что уже 1.46 вышел, а они всё никак дальше 1.44 не уйдут - вчера проверял))
С опенсорцем понятно. Я вот Qt тоже пересобираю. Но раньше я
С опенсорцем понятно. Я вот Qt тоже пересобираю. Но раньше я это делал по приколу, чтобы слоники побегали, а тут внезапно выяснил, что без этого вообще никак.
Но вообще, это же жопа.
из Qt 4.7, кстати, часть либ
из Qt 4.7, кстати, часть либ переехала в qt mobility и переименовалась. mainstream дистрибутивы afaik это пережевали, задизаблив соответслвующие части в большом Qt, а вот более мелкие иногда собирают и то и другое.
Еще msvcrt.dll забыл, из DDK ;-) А собирать под все версии
Еще msvcrt.dll забыл, из DDK ;-)
А собирать под все версии - еще тот сюр.
Для этого надо умудриться поставить мешок вижуалстудиев 2003, 2005, 2005sp1, 2008, и 2010. На подходе 2010sp1. Плюс минимум под две архитектуры - 32/64бит начиная с 2005.
Самое веселье - это когда нужно собрать под 2005 без сервиспака, а потом под 2005 с сервиспаком.
В итоге - уже 9(!) вариантов только релизных, и столько же дебажных. Может ну его нафиг, лучше на бейсике ваять? 8-)
Вот чес-слово, не понимаю - почему ребятам из DDK team вполне достаточно msvcrt.dll и добавления в проект win2003.obj (нужное подставить), а вот тиму по вижуалстудии - нет?
*Как* при этом умудряются еще продавать библиотеки, вот чег
*Как* при этом умудряются еще продавать библиотеки, вот чего я не понимаю.
Впрочем, смотрю на Intel TBB. 4 версии (vc_mt, vc8, vc9, vc10). Умножить на две битности.
Слов нет.
Вот именно, такой вот бардак. А выбора нет - зато SECURE_SCL
Вот именно, такой вот бардак. А выбора нет - зато SECURE_SCL есть, тьфу.
Эттта. DDK - это driver developers kit? Откудова там msvcrt.
Эттта. DDK - это driver developers kit? Откудова там msvcrt.dll -то? Тамж тока мессия ntoskrnl.exe и пророк его hal.dll )))
ls -l /DDK/6001.18002/lib/crt ... -rwx------+ 1 Administrat
ls -l /DDK/6001.18002/lib/crt
...
-rwx------+ 1 Administrators None 101936 2008-01-18 19:46 msvcirt.lib
-rwx------+ 1 Administrators None 102414 2008-01-18 19:46 msvcirtd.lib
-rwx------+ 1 Administrators None 1054134 2008-01-18 19:47 msvcprt.lib
-rwx------+ 1 Administrators None 2688 2008-01-18 19:10 msvcprt_btowc.lib
-rwx------+ 1 Administrators None 1056040 2008-01-18 19:47 msvcprtd.lib
-rwx------+ 1 Administrators None 1745432 2008-01-18 19:48 msvcrt.lib
-rwx------+ 1 Administrators None 1858452 2008-01-18 19:48 msvcrtd.lib
-rwx------+ 1 Administrators None 89094 2008-01-05 03:29 oldnames.lib
...
Ы?
Подсказываю - а user mode helpers как собирать? Вот именно так. Жаль, лицензия не разрешает пользовать для всего подряд.
А чисто технически - весь комплект. Даже знаменитый MFC 4.2 есть.
ахвонаонокак) Забыл уже) Да и всё юзермодовое и так в студии
ахвонаонокак) Забыл уже)
Да и всё юзермодовое и так в студии собиралось...
Иногда приходится co-installer делать, для поддержки какой-н
Иногда приходится co-installer делать, для поддержки какой-нибудь вындофс 2000 (ну, пару лет назад - приходилось). Не тащить же потом еще мешок DLL-ок в коробке ;-)
А чисто технически - вариант из DDK мне нравится наамного больше.
Никаких плясок с бубнами, никаких "ой я забыл всунуть манифест", никаких "ой, я подцепил ваш инф в контролпанели и оно там упало". И даже инсталлятор получается простым как грабли и в нем не надо помнить про vc<нумбер>-бла-бла-redist под правильную версию и правильную архитектуру.
Я б для всего пользовал - да два препятствия. Первое - это все три компилятора в DDK (под разные платформы) - разных версий. Ну и второе - это лицензия, прямо запрещающая сборку чего-либо не-околоведерного.