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