Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Cygwin" <cygwin AT sources DOT redhat DOT com>
Subject: RE: auto-import STATUS
Date: Sun, 5 Aug 2001 12:27:27 +0200
Message-ID: <001a01c11d99$39b85cb0$666307d5@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
In-Reply-To: <3B6C65B0.4060909@ece.gatech.edu>
Importance: Normal

> -----Ursprüngliche Nachricht-----
> Von: cygwin-apps-owner AT sourceware DOT cygnus DOT com
> [mailto:cygwin-apps-owner AT sourceware DOT cygnus DOT com]Im Auftrag von Charles
> Wilson
> Gesendet am: Samstag, 4. August 2001 23:14
> An: cygwin-apps AT cygwin DOT com
> Betreff: Re: auto-import STATUS
>
> 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.
>
Is should say, that I have compiled KDE 1 with this bug, but with much memory.
The real problem ar kde 2, in which some dll's and apps (kdevelop) could not be
linked.

So I think releasing this feature is no problem.

Ralf

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


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/