Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CE8B739.5060301@ece.gatech.edu>
Date: Mon, 20 May 2002 04:43:37 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: Danny Smith <danny_r_smith_2001 AT yahoo DOT co DOT nz>
CC: cygwin-apps AT cygwin DOT com
Subject: Re: binutils status?
References: <20020520080403 DOT 78375 DOT qmail AT web14506 DOT mail DOT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Danny Smith wrote:

>>>I'd say go ahead and turn on auto-import in CVS and remove the
>>>
>>warning,
>>
>>>Chuck.  I've gotten approval from Nick Clifton to do this if we
>>>
>>agree
>>
>>>it's a good idea.
>>>
>>>It's obviously a good idea.
>>>
> 
> I disagree that is a good idea. 


Two ideas:
1) making auto-import the default
2) turning off the warnings

You appear to not like either one.  I don't really care about the 
warnings, but the auto-import thing should be default.  However, I 
wonder how long these "warnings" are going to persist.  Using 
auto-import is not a *bug* or *oops, I forgot to declspec() something* 
-- it's the way DLLs are done.

I look at auto-import as "the new and better and more unixlike way of 
building shared libs".  You seem to view them as "nice feature, but you 
really ought to do it the old-fashioned way".  In my view, the warnings 
go away eventually -- they were just there during the "trial phase", 
which has now stretched to a REALLY long time.  In your view, the 
warnings are TRUE warnings about BAD programming practice, and stay forever.

> I like to now about unresolved data
> references.  I would really like to see how --auto-import works with
> new C++ ABI before I am comfortable with that switch being on by
> default.


Well, now, that's something I hadn't considered.  Good point.  Warnings 
should probably stay, then.  But that doesn't mean that auto-import 
shouldn't become the default.

 
> I've been playing with a little trick of marking _functions_ in def
> files as DATA so that only the _imp__foo name is visible in the import
> lib.  This lets me hide some of the bogons in MS libs so that I can use
> the standard function names in a better behaved  replacement version
> without any worry of duplicated definitions, but still get to the MS
> one when I need to.  Never mind, I can find another trick. I won't use
> gcc -shared to build those libs but use dlltool instead.


Urg.  Your current solution sounds extremely hackish.  Surely there's a 
better way that doesn't involve (a) marking functions as DATA (b) 
relying on --disable-auto-import being the default.  double urg.


> At least I think the warnings should be active by default.  


Given the uncertainty about the new C++ ABI in gcc-3.x, I guess you're 
right.

--Chuck