gnu cgi (cgicc) не компилируется с gcc в Windows, используя MinGW / Cygwin

Question

Мне нужно создать «доказательство концепции», используя cgicc в Windows.Но в настоящее время я не могу построить CGIC.Текущая версия cgicc v3.2.9 не будет собираться ни в MinGW (gcc v4.5.0 / v3.4.5), ни в Cygwin (gcc v4.3.4-3).

При использовании gcc v3.4.5 и automakeв MinGW я получил:

HTMLAttributeList.cpp: 51: внутренняя ошибка компилятора: в rest_of_handle_final, в toplev.c: 2067 Пожалуйста, отправьте полный отчет об ошибке, с предварительно обработанным источником, если необходимо.

Использование gcc v4.3.4 и automake дает для Cygwin:

В файле, включенном в CgiEnvironment.cpp: 36: ../cgicc/CgiEnvironment.h:52: ошибка: явное создание экземпляра классастанд :: вектор> 'в пространстве имен' cgicc ', которое не включает пространство имен' std ')

и для gcc v4.5.0 в MinGW:

.. / cgicc / CgiEnvironment.h: 52: 33:ошибка: явная реализация класса 'std :: vector'в пространстве имен' cgicc '(которое не включает пространство имен' std ')

Я пытался игнорировать сценарии Automake и Autoconf.Я настроил Eclipse-CDT для использования соответствующих ключей компилятора (я также пробовал Code :: Blocks):

-DHAVE_CONFIG_H -DWIN32 -I .. -Wall -W -pedantic -g -DDLL_EXPORT -DPIC -DCGICC_EXPORTS

Но опять же я получил:

явное создание экземпляра 'class std :: vector> 'в пространстве имен' cgicc '(которое не включает пространство имен' std ') CgiEnvironment.h / cgicc / cgicc строка 52

CgiEnvironment.h: от 51 до строки 53 содержит ifdef WIN32:

#include <string>
#include <vector>
#include <cstdlib>

namespace cgicc {
...
#ifdef WIN32
  template class CGICC_API std::vector<HTTPCookie>;
#endif
...
}

Что идет не так?Есть предложения?

Answer 1

Теперь я могу скомпилировать cgicc.Спасибо моему очень хорошему другу Владу Лазаренко и нескольким часам расследования.Но я должен сделать некоторые серьезные изменения.

Мой друг помог мне пойти по правильному пути, понимая основную проблему.Он и Влад Лазаренко дали мне хорошее руководство для расследования __declspec().Это особенность компиляторов Microsoft, которые теперь поддерживаются в gcc .

. В ходе исследования я наткнулся на сообщение с подсказками миграции для GCC3.4.3 в GCC4.1.2 ,Поэтому я перенес явную реализацию шаблонов за объявленное пространство имен в следующих заголовках:

Cgicc.h
CgiEnvironment.h
HTMLAttributeList.h
HTMLElementList.h

Затем я обнаружил странное поведение при проверке различных переключателей компилятора и других вещей, касающихся моей среды сборки.Во время исследования заголовочных файлов cgicc определенный -DCGICC_EXPORTS иногда становится неопределенным (расширение показано в Eclipse CDT).Поэтому я изменил CgiDefs.h с:

// export library symbols
#ifdef CGICC_EXPORTS
#  define CGICC_API __declspec(dllexport)
#else
#  define CGICC_API __declspec(dllimport)
#endif 

на

#  define CGICC_API __declspec(dllimport)

В конце я изменил переключатели компилятора на
-DWIN32 -DCGICC_EXPORTS -DHAVE_CONFIG_H -I.. -O0 -g3 -Wall -c -fmessage-length=0 -std=gnu++98.Наиболее важным является -std=gnu++98.Без расширений gnu __declspec() не будет генерировать символы - даже для статической библиотеки.Я не понимаю, зачем мне это нужно для статической библиотеки, потому что символы должны быть в их объектных файлах, которые упакованы в libcgicc.a.

Теперь некоторые дополнительные вопросы:

1. DoКто-нибудь знает механизм, как CGICC_EXPORTS может стать неопределенным без
   #undef CGICC_EXPORTS и без -UCGICC_EXPORTS?
2. Почему я должен использовать расширения GNU?Я думал, что значения по умолчанию независимы.
3. Почему я должен использовать __declspec(dllexport) для статической библиотеки?
4. Почему недостаточно использовать объектные файлы статической библиотеки?Позвольте мне спросить то же самое по-другому: почему не обнаруживаются символы, если я пытаюсь связать объектные файлы статической библиотеки?
5. В чем преимущество / недостаток «неявной реализации шаблона и расплывчатой ​​связи» по сравнению с «»явная реализация шаблона "?

Answer 2

CGICC_API должен быть определен как __declspec(dllimport) или __declspec(dllexport).Похоже, что макрос DLL_EXPORT, который определяется в командной строке, должен на это влиять, но это не так.Я предполагаю, что некоторая обработка заголовка не включена.См. this и that для получения дополнительной информации.