This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]
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