- gcc 4.6.2 (MinGW)
- Eclipse 3.7.1
- Win 7 Pro x86
- libCURL 7.24.0
- OpenSSL 1.0.0g
- zlib 1.2.6
- linSSH2 1.4.0
Полная версия этой страницы: gcc опции компилятора и нестыковка либ
После сборки новой версии libCURL стал нарываться на Segmentation Fault в функции curl_easy_cleanup(). Полазив по формумам, пришел к выводу, что происходит некий memory mixup - "смешивание" данных или что-то в этом роде. Ее смысл в том, что и программа сама, и библиотеки, которые она использует должны быть собраны с идентичными опциями компилятора. В студии эти опции задаются ключами /MD /MT /MTd /MDd. Как избежать такой ситуации с gcc и какие ключи компилятора аналогичны MSовским вышеперечисленным?
Вроде все эти либы есть в составе Mingw-ы. Может их прсто стянуть с офф. сайта или закачать mingw-install а не пересобирать самостоятельно?
Цитата(Tonal @ 7.2.2012, 9:16) 
Вроде все эти либы есть в составе Mingw-ы. Может их прсто стянуть с офф. сайта или закачать mingw-install а не пересобирать самостоятельно?
Ставил MinGW указав галочку Developer Tools или как-то так. Поставились только стандартные либы (аналоги из Windows SDK). На сайтах можно собранные скачать чуть по старее версии, но меня все же интересует как решить проблему в моем случае врукопашку без обходных путей.
В рукопашную - это разбиратся с системой сборки каждой библиотеки под твою конфигурацию.
По моим воспоминаниям, с zlib - это тривиально, а с OpenSSL - чёрт ногу сломит. К тому же OpenSSL тоже вроде использует zlib...
С libCURL и linSSH2 не разбирался...
Можно ещё выкачать исходники пакетов под мингву - и собрать их разобравшись с настройкой только 1 системы сборки...
По моим воспоминаниям, с zlib - это тривиально, а с OpenSSL - чёрт ногу сломит. К тому же OpenSSL тоже вроде использует zlib...
С libCURL и linSSH2 не разбирался...
Можно ещё выкачать исходники пакетов под мингву - и собрать их разобравшись с настройкой только 1 системы сборки...
в мингве опции статической линковки стандартных библиотек задаются опциями --static-libgcc и --static-libstdc++, многопоточность (точнее, обработка исключений в многопоточности) - флагом -mthreads. если это не Cygwin, то вероятно, понадобится флаг -mno-cygwin.
ещё для работы с исключениями есть флаг -fexceptions. это тоже может вызвать несовместимость.
ещё для работы с исключениями есть флаг -fexceptions. это тоже может вызвать несовместимость.
Iron Bug, поигрался я с этими опциями у себя в проекте - ничего, увы, не изменилось. Однако, виновник, видимо, найден. Убрал обращение к защищенным (HTTPS) источникам и теперь отладка проходит без ошибок, все в порядке. Вопрос в следующем: где конкретно я смог накосячить и как правильно пересобрать OpenSSL?
Makefile, по которому собирал OpenSSL после конфигурации. До этого собирал и без опции threads / enable-threads и так же нарывался на SIGSEGV.
Makefile, по которому собирал OpenSSL после конфигурации. До этого собирал и без опции threads / enable-threads и так же нарывался на SIGSEGV.
Цитата(soMan @ 9.2.2012, 3:01)
где конкретно я смог накосячить и как правильно пересобрать OpenSSL?
Флаг OPENSSL_IA32_SSE2 явно лишний.
Цитата
Don't set OPENSSL_IA32_SSE2 on x86_64.
http://www.openssl.org/gitweb.cgi?p=openss...4a43e8112ba400f
P.S. а, нет. у тебя же не 64 бита... ща ещё посмотрю, где мог быть косяк.
вот ещё подозрительная настройка:
Цитата
SHLIB_TARGET=cygwin-shared
у тебя точно cygwin, а не msys?
Цитата(Iron Bug @ 9.2.2012, 8:44)
у тебя точно cygwin, а не msys?
Как раз-таки MSYS. При конфигурации я указывал mingw и он мне сконфигурил под мингву.
Вот кусок (строка 507) из Configure, который вроде как отвечает за конфигурацию под мингву:
Цитата
# MinGW
"mingw", "gcc:-mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall::-D_MT:MINGW32:-lws2_32 -lgdi32 -lcrypt32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_asm}:coff:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a",
# As for OPENSSL_USE_APPLINK. Applink makes it possible to use .dll
# compiled with one compiler with application compiled with another
# compiler. It's possible to engage Applink support in mingw64 build,
# but it's not done, because till mingw64 supports structured exception
# handling, one can't seriously consider its binaries for using with
# non-mingw64 run-time environment. And as mingw64 is always consistent
# with itself, Applink is never engaged and can as well be omitted.
"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE::-D_MT:MINGW64:-lws2_32 -lgdi32 -lcrypt32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${x86_64_asm}:mingw64:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a",
"mingw", "gcc:-mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall::-D_MT:MINGW32:-lws2_32 -lgdi32 -lcrypt32:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_asm}:coff:win32:cygwin-shared:-D_WINDLL -DOPENSSL_USE_APPLINK:-mno-cygwin:.dll.a",
# As for OPENSSL_USE_APPLINK. Applink makes it possible to use .dll
# compiled with one compiler with application compiled with another
# compiler. It's possible to engage Applink support in mingw64 build,
# but it's not done, because till mingw64 supports structured exception
# handling, one can't seriously consider its binaries for using with
# non-mingw64 run-time environment. And as mingw64 is always consistent
# with itself, Applink is never engaged and can as well be omitted.
"mingw64", "gcc:-mno-cygwin -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE::-D_MT:MINGW64:-lws2_32 -lgdi32 -lcrypt32:SIXTY_FOUR_BIT RC4_CHUNK_LL DES_INT EXPORT_VAR_AS_FN:${x86_64_asm}:mingw64:win32:cygwin-shared:-D_WINDLL:-mno-cygwin:.dll.a",
Как видим, он автоматом подставляет cygwin-shared, (а также умудряется прилепить опцию -mno-cygwin). Правильно это или нет, все равно не знаю какими еще значениями можно это заменить. В мейк файле, по-моему, вообще проверяется не пуста ли переменная SHLIB, и, если нет - собираются дллки. Получается, черт и шо пиши в нее, он все равно соберет дллки, но я могу ошибаться.
читай доки на их сайте. потому что с опциями cygwin с msys у тебя это работать не будет. можешь также какой-нить утилькой проверить связи библиотек: они могут быть прилинкованы к разным версиям какой-то одной библиотеки, например. хотя это более маловероятно, ибо версии, как правило довольно хорошо совместимы меж собой.
Iron Bug, если нетрудно, стукни в аську (469815786), пожалуйста, есть неколько небольших вопросов, чтобы тут чат не разводить.
я аськой уже сто лет не пользовалась. я вот для нужд закупки оборудования её сегодня установила с утра, ибо нужно было достучаться до одной конторы. а так у меня её даже на компе не было. но я её не хочу запускать: там сразу все полезут общаться, а мне некогда.
я не знаю готовых решений для сборки OpenSSL. он всегда собирался через задницу и каждый раз это шаманство, но мне никогда не приходило в голову запоминать эти настройки. я каждый раз экспериментально собираю все пакеты, шарюсь по сети и ищу хинты по сборке.
я не знаю готовых решений для сборки OpenSSL. он всегда собирался через задницу и каждый раз это шаманство, но мне никогда не приходило в голову запоминать эти настройки. я каждый раз экспериментально собираю все пакеты, шарюсь по сети и ищу хинты по сборке.
Эх, сколько бьюсь, пока все без толку
. Появилось два вопроса:
1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
MSDN об ошибке:
В целом наводит на мысль, что не может он адреса эспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
. Появилось два вопроса:1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
Цитата
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "APP.EXE" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "APP.EXE" at address 0x00512212 and returned NULL. Error: (127)..
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "APP.EXE" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "APP.EXE" at address 0x00512212 and returned NULL. Error: (127)..
...
MSDN об ошибке:
Цитата
ERROR_PROC_NOT_FOUND
127 (0x7F)
The specified procedure could not be found.
127 (0x7F)
The specified procedure could not be found.
В целом наводит на мысль, что не может он адреса эспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
Эх, сколько бьюсь, пока все без толку. Появилось два вопроса:
1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
MSDN об ошибке:
В целом наводит на мысль, что не может он адреса экспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
Смотрим Таблица экспорта libeay32.dll и на строке 4051 видим:
Эх, сколько бьюсь, пока все без толку. Появилось два вопроса:
1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
MSDN об ошибке:
В целом наводит на мысль, что не может он адреса экспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
Смотрим Таблица экспорта libeay32.dll и на строке 4051 видим:
. Появилось два вопроса:1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
Цитата
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "LIBEAY32.DLL" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "LIBEAY32.DLL" at address 0x00512212 and returned NULL. Error: (127)..
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "LIBEAY32.DLL" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "LIBEAY32.DLL" at address 0x00512212 and returned NULL. Error: (127)..
...
MSDN об ошибке:
Цитата
ERROR_PROC_NOT_FOUND 127 (0x7F)
The specified procedure could not be found.
The specified procedure could not be found.
В целом наводит на мысль, что не может он адреса экспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
Смотрим Таблица экспорта libeay32.dll и на строке 4051 видим:
Цитата
OPENSSL_isservice (Ordinal: 4 048, Entry Point RVA: 16c0h (5 824))
Вначале черточки нету. WTF? Не уж то ли прибегнуть придется к -fno-leading-underscore?Эх, сколько бьюсь, пока все без толку
. Появилось два вопроса:1. Требуется ли каждый раз пересобирать libCURL после пересборки OpenSSL? (в курле указываю юзать динамический OpenSSL)
2. Посмотрел либы в Dependency Walker. Версии MSVCRT совпадают и других стандартных либ тоже. Затем сделал профилирование (она же насколько понял и отладка) и получил ошибочки при совершении запросов на защищенные ресурсы.
Цитата
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "LIBEAY32.DLL" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "LIBEAY32.DLL" at address 0x00512212 and returned NULL. Error: (127)..
...
GetProcAddress(0x00400000 [APP.EXE], "_OPENSSL_isservice") called from "LIBEAY32.DLL" at address 0x004A5D45 and returned NULL. Error: (127).
..
GetProcAddress(0x76910000 [KERNEL32.DLL], "CloseToolhelp32Snapshot") called from "LIBEAY32.DLL" at address 0x00512212 and returned NULL. Error: (127)..
...
MSDN об ошибке:
Цитата
ERROR_PROC_NOT_FOUND 127 (0x7F)
The specified procedure could not be found.
The specified procedure could not be found.
В целом наводит на мысль, что не может он адреса экспортируемых функций из дллки вытащить. Какие меры можно предпринять, чтобы стать еще ближе к причине проблемы? Может, имена экспортируемых функций не совпадают (кривой экспорт?) или еще что-то?
Смотрим Таблица экспорта libeay32.dll и на строке 4051 видим:
Цитата
OPENSSL_isservice (Ordinal: 4 048, Entry Point RVA: 16c0h (5 824))
Вначале черточки нету. Мжет ли быть эта черточка виной и почему так могло произойти?Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.