* SECURITY vulnerabilities update 2007-Sep-25 @ 2008-09-26 4:29 Yaakov (Cygwin Ports) 2008-10-02 18:13 ` Reini Urban 2008-10-27 9:19 ` Corinna Vinschen 0 siblings, 2 replies; 14+ messages in thread From: Yaakov (Cygwin Ports) @ 2008-09-26 4:29 UTC (permalink / raw) To: cygwin-apps -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Unfortunately we haven't made any progress since my last update two weeks ago, and now there's a new vulnerability (clamav). By maintainer ============= ORPAHNED: apache2 Lapo Luchini: lighttpd Reini Urban: clamav Charles Wilson: tiff, unzip By package ========== apache2 *** ORPHANED *** problem: multiple vulnerabilities (CVE-2007-6420, CVE-2008-1672/2364, CVE-2008-2939) solution: bump to 2.2.9 AND add this patch: http://svn.apache.org/viewvc?view=rev&revision=682870 info: http://www.gentoo.org/security/en/glsa/glsa-200807-06.xml (Those wishing to take this over may find this helpful: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/www/apache2/ BUT the recent patch is not included in SVN yet.) clamav problem: DoS (CVE-2008-1389/3912/3913/3914) solution: bump to 0.94 info: http://www.gentoo.org/security/en/glsa/glsa-200809-18.xml lighttpd problem: multiple vulnerabilities (CVE-2008-1270/1531) solution: bump to 1.4.19 AND apply these patches: http://sources.gentoo.org/viewcvs.py/gentoo-x86/www-servers/lighttpd/files/1.4.19-r2/ info: http://www.gentoo.org/security/en/glsa/glsa-200804-08.xml tiff problem: multiple buffer underflows (CVE-2008-2327) solution: apply this patch http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/media-libs/tiff/files/tiff-3.8.2-CVE-2008-2327.patch info: http://www.gentoo.org/security/en/glsa/glsa-200809-07.xml unzip problem: execution of arbitrary code (CVE-2008-0888) solution: apply this patch http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/app-arch/unzip/files/unzip-5.52-CVE-2008-0888.patch info: http://www.gentoo.org/security/en/glsa/glsa-200804-06.xml Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkjcZQsACgkQpiWmPGlmQSN0+gCfXB1F11rTLbLXqru2vZ5DqdrX xBcAnAk7+rOaiTCaQ1UXX3IAgswvgHmR =RVaO -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-09-26 4:29 SECURITY vulnerabilities update 2007-Sep-25 Yaakov (Cygwin Ports) @ 2008-10-02 18:13 ` Reini Urban 2008-10-27 9:19 ` Corinna Vinschen 1 sibling, 0 replies; 14+ messages in thread From: Reini Urban @ 2008-10-02 18:13 UTC (permalink / raw) To: cygwin-apps 2008/9/26 Yaakov (Cygwin Ports): > Unfortunately we haven't made any progress since my last update two > weeks ago, and now there's a new vulnerability (clamav). I'm still working on this in my spare time. 1st problem: configure:16877: result: bugged configure:16886: WARNING: ****** bzip2 libraries are affected by the CVE-2008-1372 bug configure:16888: WARNING: ****** We strongly suggest you to update to bzip2 1.0.5. configure:16890: WARNING: ****** Please do not report stability problems to the ClamAV developers! But I have libbz2-devel-1.0.5-2 And then there's a minor libtool problem I have to fix on my laptop. I'm still on a longer business trip. > clamav > problem: DoS (CVE-2008-1389/3912/3913/3914) > solution: bump to 0.94 > info: http://www.gentoo.org/security/en/glsa/glsa-200809-18.xml -- Reini Urban http://phpwiki.org/ http://murbreak.at/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-09-26 4:29 SECURITY vulnerabilities update 2007-Sep-25 Yaakov (Cygwin Ports) 2008-10-02 18:13 ` Reini Urban @ 2008-10-27 9:19 ` Corinna Vinschen 2008-10-27 16:47 ` Yaakov (Cygwin Ports) 2008-10-28 1:42 ` Charles Wilson 1 sibling, 2 replies; 14+ messages in thread From: Corinna Vinschen @ 2008-10-27 9:19 UTC (permalink / raw) To: cygwin-apps Hi guys, On Sep 25 23:28, Yaakov (Cygwin Ports) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Unfortunately we haven't made any progress since my last update two > weeks ago, and now there's a new vulnerability (clamav). > > > By maintainer > ============= > > ORPAHNED: apache2 > Lapo Luchini: lighttpd > Reini Urban: clamav > Charles Wilson: tiff, unzip any news here? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-10-27 9:19 ` Corinna Vinschen @ 2008-10-27 16:47 ` Yaakov (Cygwin Ports) 2008-10-27 20:29 ` Corinna Vinschen 2008-10-28 1:42 ` Charles Wilson 1 sibling, 1 reply; 14+ messages in thread From: Yaakov (Cygwin Ports) @ 2008-10-27 16:47 UTC (permalink / raw) To: cygwin-apps -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Corinna Vinschen wrote: >> ORPAHNED: apache2 >> Lapo Luchini: lighttpd >> Reini Urban: clamav >> Charles Wilson: tiff, unzip > > any news here? lighttpd was updated on 20 October. Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkF8GQACgkQpiWmPGlmQSPcUACdGXGO0wCGjxmB6o1tvBsyALS8 0xMAoMegWysgaSoYiXT+vbQKKLM0sLXt =Xc4F -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-10-27 16:47 ` Yaakov (Cygwin Ports) @ 2008-10-27 20:29 ` Corinna Vinschen 2008-10-28 1:24 ` Reini Urban 0 siblings, 1 reply; 14+ messages in thread From: Corinna Vinschen @ 2008-10-27 20:29 UTC (permalink / raw) To: cygwin-apps On Oct 27 11:46, Yaakov (Cygwin Ports) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Corinna Vinschen wrote: > >> ORPAHNED: apache2 > >> Lapo Luchini: lighttpd > >> Reini Urban: clamav > >> Charles Wilson: tiff, unzip > > > > any news here? > > lighttpd was updated on 20 October. Yes, right. I just forgot to delete the lighttpd line above before sending the mail, sorry. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-10-27 20:29 ` Corinna Vinschen @ 2008-10-28 1:24 ` Reini Urban 0 siblings, 0 replies; 14+ messages in thread From: Reini Urban @ 2008-10-28 1:24 UTC (permalink / raw) To: cygwin-apps 2008/10/27 Corinna Vinschen: > On Oct 27 11:46, Yaakov (Cygwin Ports) wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Corinna Vinschen wrote: >> >> ORPAHNED: apache2 >> >> Reini Urban: clamav clamav is already updated to 0.94-1 as far as I remember. >> >> Charles Wilson: tiff, unzip >> > any news here? -- Reini Urban http://phpwiki.org/ http://murbreak.at/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-10-27 9:19 ` Corinna Vinschen 2008-10-27 16:47 ` Yaakov (Cygwin Ports) @ 2008-10-28 1:42 ` Charles Wilson 2008-10-28 2:28 ` Yaakov (Cygwin Ports) 1 sibling, 1 reply; 14+ messages in thread From: Charles Wilson @ 2008-10-28 1:42 UTC (permalink / raw) To: CygWin-Apps Corinna Vinschen wrote: >> ORPAHNED: apache2 >> Lapo Luchini: lighttpd >> Reini Urban: clamav >> Charles Wilson: tiff, unzip I'm a-gettin' there. autotools first, then everything else. Related, but maybe a new topic: BTW, what's the consensus on cygwin-1.7 wrt gcc? I know there is not supposed to be -- absent runtime support library and exception unwinding issues -- any ABI breakage between gcc-3.4.5 and gcc-4.x in C. But. Our gcc-4.x could use a different runtime support library (e.g. shared libgcc if desired. Do we?). gcc-4.x also changed to dwarf2 (I think? right?) exception unwinding, which means that libgcc is a little different even when static. 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?) -- Chuck ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: SECURITY vulnerabilities update 2007-Sep-25 2008-10-28 1:42 ` Charles Wilson @ 2008-10-28 2:28 ` Yaakov (Cygwin Ports) 2008-10-29 2:22 ` gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] Charles Wilson 0 siblings, 1 reply; 14+ messages in thread From: Yaakov (Cygwin Ports) @ 2008-10-28 2:28 UTC (permalink / raw) To: cygwin-apps -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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). Yaakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkkGeKQACgkQpiWmPGlmQSOxDgCffuHEKcj+Cvl+r8i8f79ikqpE F9QAoL1qX9Qa5wuF3n7Nq2TJ1VSOUOOQ =CXoy -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 14+ messages in thread
* gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-28 2:28 ` Yaakov (Cygwin Ports) @ 2008-10-29 2:22 ` Charles Wilson 2008-10-29 4:23 ` Brian Dessent 0 siblings, 1 reply; 14+ messages in thread From: Charles Wilson @ 2008-10-29 2:22 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-29 2:22 ` gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] Charles Wilson @ 2008-10-29 4:23 ` Brian Dessent 2008-10-29 13:17 ` Charles Wilson 0 siblings, 1 reply; 14+ messages in thread From: Brian Dessent @ 2008-10-29 4:23 UTC (permalink / raw) To: CygWin-Apps 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. 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. > 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. Exception handling support: _Unwind_Backtrace _Unwind_DeleteException _Unwind_Find_FDE _Unwind_FindEnclosingFunction _Unwind_ForcedUnwind _Unwind_GetCFA _Unwind_GetDataRelBase _Unwind_GetGR _Unwind_GetIP _Unwind_GetIPInfo _Unwind_GetLanguageSpecificData _Unwind_GetRegionStart _Unwind_GetTextRelBase _Unwind_RaiseException _Unwind_Resume _Unwind_Resume_or_Rethrow _Unwind_SetGR _Unwind_SetIP __frame_state_for __gcc_personality_v0 __deregister_frame __deregister_frame_info __deregister_frame_info_bases __register_frame __register_frame_info __register_frame_info_bases __register_frame_info_table __register_frame_info_table_bases __register_frame_table Threading support: These should all map onto the respective pthreads API functions in the Cygwin DLL, so they shouldn't themselves have any state. __gnat_default_lock __gnat_default_unlock __gnat_install_locks __gthread_active_p __gthread_mutex_lock __gthread_mutex_unlock 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 The rest are mostly arithmetic, which shouldn't maintain any state: DI mode (64 bit long long) arithmetic: __muldi3 __negdi2 __lshrdi3 __ashldi3 __ashrdi3 __cmpdi2 __ucmpdi2 __divdi3 __moddi3 __udivdi3 __umoddi3 __udivmoddi4 __udiv_w_sdiv Trapping arithmetic: __absvsi2 __absvdi2 __addvsi3 __addvdi3 __subvsi3 __subvdi3 __mulvsi3 __mulvdi3 __negvsi2 __negvdi2 Bit operations: __ffssi2 __ffsdi2 __clzsi2 __clzdi2 __ctzsi2 __ctzdi2 __popcountsi2 __popcountdi2 __paritysi2 __paritydi2 __bswapsi2 __bswapdi2 Float to an integer power: __powisf2 __powidf2 __powixf2 Complex mode arithmetic: __mulsc3 __muldc3 __mulxc3 __divsc3 __divdc3 __divxc3 integer<->float conversions: __fixsfdi __fixdfdi __fixxfdi __fixunssfsi __fixunsdfsi __fixunsxfsi __fixunssfdi __fixunsdfdi __fixunsxfdi __floatdisf __floatdidf __floatdixf __floatundisf __floatundidf __floatundixf Misc: _alloca __chkstk __clear_cache __enable_execute_stack __eprintf __gcc_bcmp 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. 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. 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. Brian [1] Well, it does if you specifically ask for it with -fexceptions or -fasynchronous-unwind-tables. But AFAIK there are no C libraries in the Cygwin distro built this way. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-29 4:23 ` Brian Dessent @ 2008-10-29 13:17 ` Charles Wilson 2008-10-29 20:13 ` Brian Dessent 0 siblings, 1 reply; 14+ messages in thread From: Charles Wilson @ 2008-10-29 13:17 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-29 13:17 ` Charles Wilson @ 2008-10-29 20:13 ` Brian Dessent 2008-10-30 0:44 ` Charles Wilson 0 siblings, 1 reply; 14+ messages in thread From: Brian Dessent @ 2008-10-29 20:13 UTC (permalink / raw) To: CygWin-Apps 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-29 20:13 ` Brian Dessent @ 2008-10-30 0:44 ` Charles Wilson 2008-10-30 1:03 ` Brian Dessent 0 siblings, 1 reply; 14+ messages in thread From: Charles Wilson @ 2008-10-30 0:44 UTC (permalink / raw) To: CygWin-Apps Brian Dessent wrote: > 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. Err...but that's a good description of cygwin-1.7, as well. Nobody (as far as I am aware) is suggesting that a test/preview gcc-4.3 package should be used as a "regular" compiler for cygwin-1.5. The question is, do we take a flyer on gcc-4.3 in the cygwin-1.7 sandbox, hoping to get /all/ the kinks worked out -- in both gcc-4.3 and in cygwin-1.7 -- by the time cygwin-1.7 goes "gold". -- Chuck ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] 2008-10-30 0:44 ` Charles Wilson @ 2008-10-30 1:03 ` Brian Dessent 0 siblings, 0 replies; 14+ messages in thread From: Brian Dessent @ 2008-10-30 1:03 UTC (permalink / raw) To: CygWin-Apps Charles Wilson wrote: > Err...but that's a good description of cygwin-1.7, as well. Nobody (as > far as I am aware) is suggesting that a test/preview gcc-4.3 package > should be used as a "regular" compiler for cygwin-1.5. I thought so as well, but people are already putting stuff built with gcc4 into the distro: <http://cygwin.com/ml/cygwin-announce/2008-09/msg00017.html>. > The question is, do we take a flyer on gcc-4.3 in the cygwin-1.7 > sandbox, hoping to get /all/ the kinks worked out -- in both gcc-4.3 and > in cygwin-1.7 -- by the time cygwin-1.7 goes "gold". I guess all I'm saying is that the minimum precondition before we should even think about starting to recompile anything is that gcc4 should default to shared and versioned libgcc. Until then it's just going to create more headaches to deal with later. Brian ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2008-10-30 1:03 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-26 4:29 SECURITY vulnerabilities update 2007-Sep-25 Yaakov (Cygwin Ports) 2008-10-02 18:13 ` Reini Urban 2008-10-27 9:19 ` Corinna Vinschen 2008-10-27 16:47 ` Yaakov (Cygwin Ports) 2008-10-27 20:29 ` Corinna Vinschen 2008-10-28 1:24 ` Reini Urban 2008-10-28 1:42 ` Charles Wilson 2008-10-28 2:28 ` Yaakov (Cygwin Ports) 2008-10-29 2:22 ` gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25] Charles Wilson 2008-10-29 4:23 ` Brian Dessent 2008-10-29 13:17 ` Charles Wilson 2008-10-29 20:13 ` Brian Dessent 2008-10-30 0:44 ` Charles Wilson 2008-10-30 1:03 ` Brian Dessent
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).