Brian Dessent wrote: > Charles Wilson wrote: > >> Or is all the worry about about unwinding a C++ only issue? (And of > > As far as I can tell, it is.
Okay, thanks. > Note that gcc doesn't[1] emit any unwind tables for C language input, > even on platforms like Linux that have been DW2 for a long time. So if > you somehow managed to get yourself into a situation where you were > throwing from a C++ frame and the unwinder encountered a C frame, it > would call terminate() there too -- that would be undefined behavior. Ack. But that'd be true on *nix, too. >> 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? > > Aside from the EH issue, I don't think that there would be any problem. > Here is a list of all the functions exported by libgcc.a and > libgcc_eh.a. With the obvious exception of the EH ones and possibly the > tlsemu ones, I don't see any that would carry any inherent state > information such that they would get confused by one caller getting the > static version and another the one from a libgcc DLL. > [snip] > TLS support: > These might carry some shared state and require -shared-libgcc. > However, since this did not exist prior to 4.3 there's no backwards > compatibility issue either. > __emutls_get_address > __emutls_register_common Hmm. But, if some existing package -- even a C-only one -- is rebuilt with TLS support enabled (I don't know of any, I'm just speculating here) -- then the new version will require all clients to also link using -shared-libgcc. So, if any maintainer makes this choice for package X-with-TLS, that'll require a version bump. Or, we could just assert gcc-4.3 + -shared-libgcc should be the default for on-going cygwin-1.7-specific work, which would require all shared libraries to get version bumped anyway. 'Course, any package (re)compiled on cygwin-1.5 using gcc-3.4.5 would link against the cygwin-1.5 cygfoo-A.dll at compile time, and when/if mirrored to release-2 would bind at runtime to...the cygfoo-A.dll from release-2. But that's exactly the behavior we expect and want. cygfoo-A.dll is "the backwards compatible" runtime. Any new non-compatible one will exist in release-2 only, and will be cygfoo-B.dll. > The rest are mostly arithmetic, which shouldn't maintain any state: Ack. > > IMHO, shared libgcc needs to be the default and all C++ libraries (and > applications that link to C++ libraries) will need to be rebuilt to use > it. Eventually, sure. > But at the moment this is a problem because: > > a) gcc-4 still defaults to static libgcc, requiring -shared-libgcc flag > to link with the DLL > b) libgcc DLL is named just cyggcc_s.dll, but it should be versioned > c) the shared gcc runtime package is currently named just > "gcc4-runtime", but it should be both versioned and split into > individual components, i.e. we should have libgcc0, libstdc++6, > libgfortran0, and so on, however: > d) shared libstdc++ doesn't exist yet because of the operator new/delete > overriding issue. > > At the moment it looks like our best option is to leave static libstdc++ > the default but have a shared option available for code that doesn't > need to override operator new/delete, until (d) is fixed at which point > we make shared the default. 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++? > Ideally for future sanity I think we need > to get away from all these static copies of the runtimes being default > and make everything use DLLs, but I understand that's not practical > right now. Understood. Pending answers above, I'm leaning towards one of the following two scenarios for my packages on 1.7. I agree with Yaakov that now would be a good time to transition to 4.3 [*] provided the birth pains aren't...well, like birth pains. [*] although the soon-to-be-released 4.4 looks really juicy. Sigh. One thing at a time. SCENARIO 1) rebuild all using gcc-4.3, using the default static libgcc and static libstdc++ runtimes. C libraries will not get version bumped (unless they need it for another reason). C++ libraries will get version bumped. Given the assurances above, it appears that clients of the non-version-bumped libraries won't have any issues. Later, once the issues with shared libstdc++ and new/delete, packaging of the runtimes, versioning of the shared runtime, etc etc, are resolved, again rebuild all using gcc-4.3 with -shared-gcc and -shared-libstdc++ (or wait for the gcc-4.3 release with that behavior turned on by default), and version bump everything again. At this point, clients will probably have issues -- but that's okay, everything is being version bumped. SCENARIO 2) rebuild all using gcc-4.3, using the -shared-libgcc but static libstdc++ runtimes. C libraries will get version bumped (because clients need to link using -shared-libgcc). C++ libraries get version bumped too, because of the 3.4.5->4.3 ABI changes. Clients will probably have issues -- but that's okay, because everything is being version bumped. Later, once all the issues are adressed, rebuild the c++ libraries again with -shared-libstdc++ (or the new shared default behavior of the 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. Gven all these version bumps...clients will need to be rebuilt (with the new -shared-libgcc -shared-libstdc++ flags, or the new defaults) to use the new DLLs. That's a lot of rebuilding. #1 is has the possibility of being less work overall -- but probably not; both scenario 1 and 2 will likely end up looking like "rebuild everything twice" and "version bump everything at least once, maybe twice". I'd still prefer #2 because it gets us to shared-libgcc sooner (phase 1, rather than phase 2), assuming you can mix shared-libgcc and static-libstdc++. -- Chuck
