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: <3B5B0686.5050500@ece.gatech.edu>
Date: Sun, 22 Jul 2001 12:59:50 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Travis Howell <kirben AT optushome DOT com DOT au>
CC: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>, cygwin-apps AT cygwin DOT com
Subject: Re: ld --auto-import for cygwin and libtool
References: <020601c0f27b$d579ea90$0200a8c0 AT lifelesswks> <02a701c11289$bc8b9b90$562fa4cb AT co3007967a> <007e01c112b0$a6de11c0$806410ac AT local> <033a01c112b2$306e53e0$562fa4cb AT co3007967a>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Travis Howell wrote:


>>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