SECURITY vulnerabilities update 2007-Sep-25

SECURITY vulnerabilities update 2007-Sep-25

[Yaakov (Cygwin Ports)]

-----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-----

Re: SECURITY vulnerabilities update 2007-Sep-25

[Reini Urban]

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/

Re: SECURITY vulnerabilities update 2007-Sep-25

[Corinna Vinschen]

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

Re: SECURITY vulnerabilities update 2007-Sep-25

[Yaakov (Cygwin Ports)]

-----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-----

Re: SECURITY vulnerabilities update 2007-Sep-25

[Corinna Vinschen]

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

Re: SECURITY vulnerabilities update 2007-Sep-25

[Reini Urban]

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/

Re: SECURITY vulnerabilities update 2007-Sep-25

[Charles Wilson]

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

Re: SECURITY vulnerabilities update 2007-Sep-25

[Yaakov (Cygwin Ports)]

-----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-----

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

[Charles Wilson]

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

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

[Brian Dessent]

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.

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

[Charles Wilson]

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

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

[Brian Dessent]

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

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

[Charles Wilson]

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

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

[Brian Dessent]

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