Mail Archives: cygwin-apps/2001/07/22/20:15:55
From: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
> >>I don't believe that this has _ever_ been supported by cygwin. Paul
> >>Sokolovsky created this hack himself.
> >>
> >
> > I'm sure binutils-20000722-1 allowed auto importing of symbols and that
was
> > broken/removed in binutils-20001029-1+.
> >
>
>
> Nope. 20000722-1 was released after dj, cgf, and I finished up a major
> round of binutils hacking. The creation of dll's from binutils had
> completely bitrotted due to Mumit's year long absence. We restored it.
> But we did nothing to allow auto-importing of symbols without the need
> for __declspec() in the source code, for DATA exports. It is true,
> however, and still IS true, that you don't REALLY need __declspec() for
> FUNCTION exports. (*)
>
> Repeat: 20000722-1 REQUIRES declspec() modifiers in the code for DATA
> exports.
>
> (*) if a dll is built with __declspec(dllexport) modifiers on functions,
> then you DO need __declspec(dllimport) modifiers to link to those
> functions in the dll. function-auto-import only works if both dll and
> client-exe are built without decorators. AFAIK, Paul's "auto-import"
> patch extends this behavior to DATA as well as functions -- but both DLL
> and client-exe must be built the same way, even with Paul's patch.
If nothing changed, then why exactly does this work in binutils 20000722:
char *assoc_start();
But in all binutils releases since then I have to use:
#if defined (__CYGWIN__) && !defined(STATIC)
__declspec(dllexport) char * __cdecl assoc_start();
#else
char *assoc_start();
#endif
Or I symbol not defined not errors, this code uses only function exports.
- Raw text -