В исходниках Colorer`а помимо проектных файлов для Visual C++, есть makefile для cygwin и mingw. Была у меня мысль, да и сейчас есть, перенести сборку полностью на gcc на mingw. После доработок Colorer под версию 1.0.3 поправил makefile, и приступил к сборке. Для сборки же решил использовать
TDM-GCC версии 4.5.1 . Сборка прошла успешно, а вот Far падал при первом же обращении к плагину. На VC++ такого не было. Рыл код, смотрел опции компиляции, ничего не помогает. Так ведь еще и не понятно в каком месте падает.
Решил попробовать собрать отладочную версию в gcc. Но добавление соответствующих опций не давало эффекта. Отладочная информация не добавлялась к файлу. Проблему еще предстоит решить, хотя бы из спортивного интереса.
На эту фигню, так сказать, было убито дня 3. Решение родилось как то по крупицам. Для отладки релизных версий программ часто используется map-файл.
Тут можно почитать пример его использования. А в Far есть полезная библиотечка FExcept (странно что про неё ни написано хотя бы рекомендаций по использованию). Если она подключена, то при падении Far будет формироваться файл trap.log . В этом файле содержится стэк вызова функций/процедур, значения регистров и т.п. . Т.е. то, что обычно видно в отладчике. Файл формируется по map файлу Far`а и плагина. По этому трапу мы видим место падения. Ну а дальше дело техники.
В моем случае ошибка была в том, что gcc, в отличии от vc++, не подключил DllMain как внешнюю вызываемую функцию. Что исправляется двумя словами
extern "C" BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason, LPVOID lpReserved )
На этом приключения не закончились. Сборка прошла, все работает. Но интересно ведь увидеть повлияло ли смена компилятора на скорость. Для этого собрал с помощью того же tmd-gcc утилиту colorer.exe и запустил тест на скорость работы. Удивления не было предела - скорость упала больше чем в 2 раза. С помощью пользователя far-форума chupakabra было установлено, что виноват компилятор, а не опции компилирования. Он же создал вопрос на форуме
mingw-w64. Разработчики подтвердили ошибку компилятора, и что она уже должна быть исправлена в trunk версии. Осталось проверить исправленную версию.
