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: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Message-ID: <009d01c11315$90a94d60$562fa4cb@co3007967a> From: "Travis Howell" To: "Charles Wilson" Cc: 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> Subject: Re: ld --auto-import for cygwin and libtool Date: Mon, 23 Jul 2001 11:19:48 +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 I tried using that older binutils 20000722-1 again along with downgrading the rest of Cygwin and it still works fine with data exports! Are you sure you aren't getting the binutils versions confused ? the announcement ( http://sources.redhat.com/ml/cygwin-announce/2000/msg00041.html ) for 20000722-1 mentions nothing much changed but the announcement ( http://sources.redhat.com/ml/cygwin-announce/2000/msg00091.html ) for 20001029 mentions several changes from dj, cgf and you. ----- Original Message ----- From: "Charles Wilson" > >>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. > > My concern at the moment is: can DLL's built with Paul's binutils > interoperate with previously-linked client exe's. (ESPECIALLY: > cygwin1.dll itself!) Can client exe's linked by Paul's binutils > interoperate with earlier (pre-Paul) DLL's? That's what I'm testing > currently, along with checking out some of Robert's recent libtool > improvements that use Paul's binutils. > > Oh yeah: and one final concern. Currently, folks with Windows-XP-beta > are having trouble with cygwin in general. Once cygwin actually works on > Windows-XP-[beta/rc/gold/whatever], THEN: will Paul-style DLL's be > acceptable to the windows-XP runtime linker? Paul-style DLL's *do* > slightly violate the PE spec, after all...even though the runtime > linkers on WinNT, Win2K, WinME, and Win9x all seem happy. > > --Chuck > > >