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: <3B6C65B0.4060909@ece.gatech.edu>
Date: Sat, 04 Aug 2001 17:14:24 -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: cygwin-apps AT cygwin DOT com
Subject: Re: auto-import STATUS
References: <20010803233635 DOT 73332 DOT qmail AT web14506 DOT mail DOT yahoo DOT com> <3B6C4156 DOT 7060404 AT ece DOT gatech DOT edu> <20010804144836 DOT C3038 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:

> On Sat, Aug 04, 2001 at 02:39:18PM -0400, Charles Wilson wrote:
> 
>>So, perhaps the logic that adds thunking symbols for DATA exports in 
>>DLLs needs to be re-examined, to make sure it covers these special 
>>cases, esp. "static" fields of classes, and inner classes, (and "static" 
>>fields OF inner classes...)
>>
>>Unfortunately, I can't really pursue this -- or anything else 
>>cygwin-related -- for the next week or so.  My laptop broke (mechanical) 
>>and I have to send it back to Dell for repair.  But, I have no other 
>>machine that's configured for cygwin development, so I'm out of action 
>>for more than a week.  (Plus, for a different reason, I'll be out of 
>>email contact Sunday/Monday.)
>>
>>Can somebody else please pursue this (and perhaps the other things 
>>mentioned in the first message of this thread), now that I've managed to 
>>push the initial auto-import into binutils CVS ?
>>
> 
> So, should I hold off on releasing a new binutils for now?  Or, should I
> just mark it experimental, maybe?


Well, I dunno.  I should point out that the current CVS binutils DOES 
work for C++ -- at least when tested according to my 2nd version of 
dllhelpers. (*)

I was just brainstorming that message (which you partially quoted 
above).  Perhaps the problem isn't really a problem (like the "KNOWN 
ISSUES" things are not really problems).  Perhaps there IS a problem, 
but it really isn't inner classes, but templates.  In THAT case, since 
I'm not a C++ programmer:

How often are templates used?  Is it bad to say, for now, [IF this is 
even true!], "if you want to use templates, you must use __declspec()"

Let's put it this way: the CVS binutils works as well as the old 
binutils, when used to link identical source code/object files.  The new 
version adds some additional features, which are not used by default, 
which themselves may be considered experimental:

Not because the new features don't work, but because there MAY be cases 
in which the new feature is less helpful than we'd like.  BUT, as a 
counter-argument, there MAY also be cases where the current binutils breaks.

With every release (of anything, incl. binutils), we're just waiting for 
those reports; we can't fix what we don't know about.  Danny (and Ralf) 
have isolated possible areas to watch -- but haven't *really* done 
thorough enough testing to definitively say "yep, there's a bug". 
(Okay, Ralf has actually pinpointed a true bug (I think), but I'm not 
sure Danny has; Ralf's bug needs fixing, but only causes problems when 
creating DLLs with HUGE numbers of objects.)

Now, if you're asking whether to delay merely because I will be in 
non-developer status for the next week -- I don't think that's really 
necessary.  I'll be (mostly) in email contact, and I'm not the only 
person who understands the innards of binutils.  Hell, I didn't even 
write the auto-import stuff. Surely between Paul, Rob, Ralf, Danny, DJ, 
... I am replaceable for a short time!

So, IMO, go ahead and release it. If you're nervous about Ralf's bug, 
release as experimental.  Otherwise, go for it.

--Chuck

(*) My first revision of Mumit's dllhelpers (0.2.6) updated his code to 
use 'gcc -shared' instead of dlltool.  My second revision (to be posted 
today, 0.2.7) will use auto-import, for both C and C++.