This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
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.
--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++.