Russian Qt Forum
Ноябрь 05, 2024, 19:34 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: [1]   Вниз
  Печать  
Автор Тема: shared Qt со статическим CRT  (Прочитано 5466 раз)
silart
Гость
« : Июль 15, 2008, 11:15 »

Добрый день всем!
Кто-нибудь пытался собрать Qt таким образом? возможно ли это?

Проблема в том, что некоторые файлы из папки bin после компиляции перестали запускаться и выдают ошибки (assistant.exe например).
Но это еще не все. Когда я собираю свой проект с этими версиями библиотек, debug-версия выдает следующую ошибку: file dbgheap.c, line 1279, expression: _CrtIsValidHeapPointer(pUserData). В release-версии все работает нормально.
Что еще более странно, если MSVCRT не делать статической, подобных проблем не возникает.

Что я делаю не так при сборке Qt?
« Последнее редактирование: Июль 15, 2008, 13:08 от pastor » Записан
pastor
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 2901



Просмотр профиля WWW
« Ответ #1 : Июль 15, 2008, 13:13 »

Лично я не пробывал так собирать.

У меня возникает вопрос - зачем? Я бы понял если собиралась бы "true static Qt"... А тут "shared Qt со статическим CRT" несовсем понятна цель таких действий. Всеравно будете тягать набор Qt-шных dll, в чем проблема тягать ещё 2 CRTшные библиотеки?
Записан

Integrated Computer Solutions, Inc. (ICS)
http://www.ics.com/
Alex03
Гость
« Ответ #2 : Июль 15, 2008, 14:58 »

Плюс появляется возможность линковки Qt и самого приложения с разными CRT, что не есть гуд как по объёму, так и по возможным граблям, как то вызов malloc() (new) одной либы и free() (delete) другой и т.д.
Записан
silart
Гость
« Ответ #3 : Июль 15, 2008, 15:18 »

Ну все ясно. Придется от этой затеи отказаться. Просто эти 2 dll еще лежат по такому пути, что фиг найдешь. Теперь стало понятно почему у меня возникали глюки при запуске программ из папки bin после такой компиляции. А если эти библиотеки CRT положить в папочку со своим исполняемым файлом, работать будет? Или обязательно нужно чтобы они лежали на своем месте?
Записан
pastor
Administrator
Джедай : наставник для всех
*****
Offline Offline

Сообщений: 2901



Просмотр профиля WWW
« Ответ #4 : Июль 15, 2008, 15:32 »

Ну все ясно. Придется от этой затеи отказаться. Просто эти 2 dll еще лежат по такому пути, что фиг найдешь. Теперь стало понятно почему у меня возникали глюки при запуске программ из папки bin после такой компиляции. А если эти библиотеки CRT положить в папочку со своим исполняемым файлом, работать будет? Или обязательно нужно чтобы они лежали на своем месте?

Почитайте вот это:

http://doc.trolltech.com/4.4/deployment-windows.html
Записан

Integrated Computer Solutions, Inc. (ICS)
http://www.ics.com/
Red Devil
Гость
« Ответ #5 : Июль 15, 2008, 16:16 »

А если эти библиотеки CRT положить в папочку со своим исполняемым файлом, работать будет? Или обязательно нужно чтобы они лежали на своем месте?
При запуске библиотеки ищутеся в первую очередь из того каталога из которого запущен бинарник. Далее перебираются все каталоги указанные в переменной окружения PATH. Это касательно виндоус.
В линукс, я не уверен, но кажется вначале ищется в первую очередь в каталогах указаных в переменной окружения LD_LIBRARY_PATH. затем во всех каталогах которые указаны в переменной окружения PATH, в своем каталоге не ищется.
Записан
Alex03
Гость
« Ответ #6 : Июль 16, 2008, 07:12 »

При запуске библиотеки ищутеся в первую очередь из того каталога из которого запущен бинарник. Далее перебираются все каталоги указанные в переменной окружения PATH. Это касательно виндоус.
В винде не всё так просто, и более того зависит от ОС!
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

В MSDN MSVS 2005 несколько по другому, так ещё и вот это:
Цитировать
Legacy Search Order

Earlier versions of Windows do not support the SafeDllSearchMode value. The DLL search order is as follows.

Windows 2000/NT:  The system searches for DLLs in the following order:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.

Windows Me/98/95:  The system searches for DLLs in the following order:
The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable.

В линукс, я не уверен, но кажется вначале ищется в первую очередь в каталогах указаных в переменной окружения LD_LIBRARY_PATH. затем во всех каталогах которые указаны в переменной окружения PATH, в своем каталоге не ищется.
Там ещё LD_PRELOAD бывает и т.д. В общем лучше обратиться к первоисточнику.
« Последнее редактирование: Июль 16, 2008, 07:37 от Alex03 » Записан
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.06 секунд. Запросов: 23.