gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
>> So...should cygwin-1.7 packages all be built using gcc-4.x, or not? (And
>> is it really, as I fear, an all-or-nothing proposition given the libgcc
>> changes?)
> 
> I'm not sure how much this is all-or-nothing for C, but I imagine that
> it would be for C++.
> 
> But I very seriously think that everything should be rebuilt with
> cygwin-1.7 and gcc-4.3, as this is the best time to make that transition
> (as well as give both a through testing before stabilizing).

I understand the argument, but I *really* need official word about the
compatibility issues (Dave? Danny? Bueller?)  Fer instance, suppose I
rebuild the ncurses package using gcc-4.3 (ignoring the C++ issue, for now).

If I build using a static libgcc.a, do I need to version bump
cygncurses-N.dll, or will existing clients -- compiled using gcc-3.4.5
and using the sjlj unwinding code those clients statically inherited
from gcc-3.4.5's libgcc.a -- work ok?

If I build using a shared libgcc, do I need to version bump
cygncurses-N.dll? Same question: do all clients of cygncurses-N.dll need
to use the same unwinding protocol and libgcc "flavor"?

Or is all the worry about about unwinding a C++ only issue? (And of
course, the C++ cygncurses++-N.dll needs to be version bumped anyway if
built with 4.3, because the C++ ABI definitely changed between 3.4.5 and
4.x)

But even if the unwinding differences (sjlj vs dwarf2) are NOT an issue
for C libraries, will there be incompatibilities between C client apps
that use static 3.4.5 libgcc.a and my C DLLs that use (static? shared?)
4.3 libgcc?

I was hoping to see this issue thrashed out by now, but sadly no.  Which
is why I'm currently working only on packages that have no compiled
component (autotools, csih) or have no library dependencies beyond
cygwin1.dll itself (cvs, zip, unzip, p7zip, login, ...)

--
Chuck