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

[Brian Dessent <brian@dessent.net>]

Charles Wilson wrote:

> Well, if we continue -- at present -- with static libstdc++, then would
> we need to continue -- at present -- with static libgcc even for C
> libraries?  For example:
> 
> cygncurses-N.dll : if this C library is compiled using -shared-libgcc
> 
> then
> 
> cygncurses++-N.dll : this C++ library can't be linked (right?) It's C++,
> but depends on cygncurses-N.dll. From what I understand, you have to
> have static libgcc and static libstdc++, or shared libgcc and shared
> libstdc++, you can't mix them. And because you can't link against
> cygncurses-N.dll (which was linked against the shared libgcc) without
> specifying -shared-libgcc when linking your client...boom.
> 
> Or, am I wrong on that (I'd love to wrong about that) -- if so, then you
> CAN do what would effectively be -shared-libgcc -static-libstdc++?

I'm not aware of anything that would preclude mixing static libstdc++
and shared libgcc.  It needs some testing, obviously.

> updated gcc-4.3). Version bump the C++ libraries again.  However, if one
> of the "issues" is the versioning of the libgcc shared library, then the
> C libraries will ALSO have to be rebuilt again -- but they may (or may
> not) have to be version bumped again at that time.  They probably will.
>  Clients from scenario 2/phase 1 expect the "old" cyggcc_s.dll -- which
> was fine with cygncurses-N.dll which also used cyggcc_s.dll.  However,
> this new cygncurses-N.dll depends on cyggcc_s-2.dll so now the client
> will pick up two different runtime support libraries: cyggcc_s.dll
> directly, and cyggcc_s-2.dll via cygncurses-N.dll. That's bad.  So, even
> the C libraries will need the second version bump, for scenario 2/phase 2.

Yes, this is why having an unversioned but shared libgcc in the distro
is such a poison.  With the current state of gcc4 it's impossible to win
as maintainer of a C++ library: if you use the default options you get
static libgcc which means your library can't throw or catch exceptions
from other modules.  If you use -shared-libgcc you get a dependence on
an unversioned shared lib which makes the output unsuitable to be
released to the public in the distro because it will only cause
headaches later.  So I consider this gcc4 package to be in a preview
state, but it its output should not be considered suitable for packaging
yet.

Brian