Russian Qt Forum

Есть софтина написанная и собранная под 32ух битной ОС (Windows 7), при переносе на 64ох битную выдает ошибки

Первый раз сталкиваюсь с таким переносом, подскажите может нужно собирать софт с какими то ключиками или еще что по колдовать, компилятор MinGW gcc - 4.4.5 .

 

означает - access violation

стандартная ошибка, проявляющаяся при переносе с 32ух битной на 64ех битную ОС.
причина, как правило, в неправильном результате, при арифметической операции с указателями.
лечится, путем избегания в арифметических операция с указателями, смешанных целочисленных типов - int, unsigned int, unsigned long, size_t.
для индексирования, существует тип ptrdiff_t. для арифметических - size_t, и еще некоторые.

читать тут: http://www.viva64.com/terminology/ptrdiff_t_rus.html

Судя по логу приложение получилось не 64-х битным, адреса короткие. Или 32-х битная конкретная либа qgif4.dll
Qt собрана под 64 бита? Вся? И плагины? ;)

Сейчас видимо будете смеяться, прога и Qt собранны под 32, потом запущена под 64 битной ОС, причем все либы и плагины были от Qt собранной под 32,  насколько я понимаю нужно делать две версии софта, одну под 32 бита вторую под 64, и стало быть под каждую из них пересобирать Qt и сопутствующие либы?

Wicked_Digger, 32ух битный код обязан работать на 64ех битной платформе.
тут либо троли напортачили(что маловероятно), либо ТС каким-то образом имеет к этому отношение ;)

нет, нет, и нет.

Я запросто мог, буду вечером качать 64 битную ОС, и тестить, постараюсь не сойти с ума :)


Это радует, если косяки в софтине, то отловить их проще будет.

Я так понял, что приложение портировалось под 64 бита. Если нет, то должно работать без проблем. Возможно стоит использовать Qt 6.X, т.к. в ней есть изменения связанные с Win7. Возможно изменились какие-то системные вызовы.

надеюсь, имелось ввиду "4.6.Х", а не "6.Х", а то страшно после выходных видеть подобное - неужто я так много пропустил? =)

1) На всех платформах все либы, как статические, так и динамические должны сбиваться - все должно быть либо 32, либо 64. Никак не вызвать 32-битную dll из 64 кода и наоборот. Про ключики не подскажу, т.к. работаю в IDE. Просто создал новый target и выбрал для него архитектуру 64. На Вындоуз (MSVC 2008) - аналогично.

2) "Болезненность" переноса на 64 разная, мне пришлось тяжело с проектом на "С" - эффективный но низкоуровневый код с массой предположений что адрес 4 байта. На Mac платформе плюс еще 1 заморочка - long 8 байт в 64 (но 4 в 32). Пришлось избавиться от всех (unsigned) long.

3) Конечно, все 32-битные выполняются на 64-битном OC. Поэтому если "не горит" и заказчик не рвется использовать больше памяти - то практичнее с переводом повременить. Напр. 4 Gb могут быть совсем не "в 2 раза больше" по сравнению с 2 Gb на 32, т.к. 64-битное приложение может жрать ощутимо больше (зависит от задачи). В смысле скорости 64 ничего не дает. Память приходится экономить и учитывать так же. Ее просто у заказчика может быть намного больше - но это все

Вылет был в плагинах imageformats, я просто перед тем как сделать инсталяшку все плагины и dll сжал upx-ом, после того как откатил до нормальной версии плагины, вылетать перестало, ну и на крайний случай прошелся по софтине и заменил int на size_t где это возможно :)