Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <007d01c1130f$68503a50$562fa4cb@co3007967a>
From: "Travis Howell" <kirben AT optushome DOT com DOT au>
To: "Charles Wilson" <cwilson AT ece DOT gatech DOT edu>
Cc: <cygwin-apps AT cygwin DOT com>
References: <020601c0f27b$d579ea90$0200a8c0 AT lifelesswks> <02a701c11289$bc8b9b90$562fa4cb AT co3007967a> <007e01c112b0$a6de11c0$806410ac AT local> <033a01c112b2$306e53e0$562fa4cb AT co3007967a> <3B5B0686 DOT 5050500 AT ece DOT gatech DOT edu> <005901c1130c$cbb55b00$562fa4cb AT co3007967a>
Subject: Re: ld --auto-import for cygwin and libtool
Date: Mon, 23 Jul 2001 10:35:43 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200

From: "Travis Howell" <kirben AT optushome DOT com DOT au>
> > >>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.

Oops nevermind there are a few variables in that source code after all,
strange that it used to compile with binutils 20000722 though.