gnu cgi (cgicc) does not compile with gcc on Windows using MinGW/Cygwin

I have to build a "proof of concept" using cgicc on Windows. But currently I am unable to build cgicc. The current release of cgicc v3.2.9 won't build neither in MinGW (gcc v4.5.0 / v3.4.5) nor Cygwin (gcc v4.3.4-3).

By using gcc v3.4.5 and automake in MinGW I got:

HTMLAttributeList.cpp:51: internal compiler error: in rest_of_handle_final, at toplev.c:2067 Please submit a full bug report, with preprocessed source if appropriate.

Using gcc v4.3.4 and automake gives for Cygwin:

In file included from CgiEnvironment.cpp:36: ../cgicc/CgiEnvironment.h:52: error: explicit instantiation of 'class std::vector<cgicc::HTTPCookie, std::allocator<cgicc::HTTPCookie> >' in namespace 'cgicc' which does not enclose namespace 'std')

and for gcc v4.5.0 in MinGW:

../cgicc/CgiEnvironment.h:52:33: error: explicit instantiation of 'class std::vector<cgicc::HTTPCookie>' in namespace 'cgicc' (which does not enclose namespace 'std')

I tried to ignore the Automake and Autoconf scripts. I set up Eclipse-CDT for using the apropriate compiler switches (I also tried Code::Blocks):

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

But again I got:

explicit instantiation of 'class std::vector<cgicc::HTTPCookie, std::allocator<cgicc::HTTPCookie> >' in namespace 'cgicc' (which does not enclose namespace 'std') CgiEnvironment.h /cgicc/cgicc line 52

CgiEnvironment.h:51 to line 53 contains the ifdef WIN32:

#include <s开发者_如何学Gotring>
#include <vector>
#include <cstdlib>

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

What goes wrong? Any suggestions?

---

Now I can compile cgicc. Thanks to a very good friend of mine, Vlad Lazarenko and some hours of investigation. But I have to do some major changes.

My friend helped me to go on the right way by understanding the main issue. He and Vlad Lazarenko gave me a good direction to investigate the __declspec(). This is a feature of Microsoft compilers which are now supported in gcc.

During investigation I stumbled over a post with migration hints for GCC3.4.3 to GCC4.1.2. So I moved the explicit instantiation of the templates behind the declared namespace in following headers:

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

Next I discovered a strange behaviour while checking different compiler switches and other things regarding my build environment. During investigatiopn of cgicc header files the defined -DCGICC_EXPORTS becomes sometimes undefined (expansion is shown by Eclipse CDT). So I changed CgiDefs.h from:

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

to

#  define CGICC_API __declspec(dllimport)

At the end I changed the compiler switches to
-DWIN32 -DCGICC_EXPORTS -DHAVE_CONFIG_H -I.. -O0 -g3 -Wall -c -fmessage-length=0 -std=gnu++98. Most important is -std=gnu++98. Without gnu extensions __declspec() wont generate any symbols - even for a static library. I do not understand why I need that for a static library because the symbols should be in their object files which are packet into libcgicc.a.

Now some further questions:

1. Do anyone know a mechanism how CGICC_EXPORTS can became undefined without
   #undef CGICC_EXPORTS and without -UCGICC_EXPORTS?
2. Why I have to use gnu extensions? I thought the defaults are independend.
3. Why do I have to use __declspec(dllexport) for a static library?
4. Why it is not enough to use the object files of a static library? Let me ask the same in a different way: Why are no symbols found if I try to link object files of a static library?
5. What is the advantage/disadvantage of "implicit template instantiation and vague linkage" versus "explicit template instantiation"?

---

The CGICC_API should be either defined as __declspec(dllimport) or __declspec(dllexport). It looks like that DLL_EXPORT macro that gets defined in command line should affect that, but it doesn't. My guess is that some header handling it is not included. See this and that for more information.