X-Spam-Check-By: sourceware.org
Message-ID: <4673E461.80960A59@dessent.net>
Date: Sat, 16 Jun 2007 06:23:45 -0700
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Some notes on building gcc-4.3.0
References: <466F9B52 DOT 1000709 AT cwilson DOT fastmail DOT fm> <4672C1F4 DOT 6010306 AT users DOT sourceforge DOT net> <46736405 DOT 2010303 AT cwilson DOT fastmail DOT fm>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Charles Wilson wrote:

>     C++ exceptions across DLL boundaries [*]
> This also affects java.  It is /NOT/ solved in 4.2, nor svn trunk.  The
> Official Way Forward is to get shared runtimes working...which explains
> my patch-in-progress, above.

For the MinGW community for sure, and for the Cygwin community to a much
lesser extent, I can guarantee there are going to be people upset by
having to distribute these shared target libs
{cyg,lib}{gcc_s,stdc++}.dll with their app.

I predict they will turn to using the -static-libgcc option, which it
seems will cause broken exception handling in these cross-.so
circumstances.  Not that this is any different on Linux, where apps that
want to throw/catch cross-.so will break with -static-libgcc, but at
least there it is custom and typical to have the shared target libraries
installed as part of the distro.  Windows users seem infatuated with
this "everything comes in the installer" mentality.

Are we really going to tell them that there is no choice in the matter,
that if they want cross-.so EH they must suffer shared libraries?  They
will probably complain that they could get what they wanted from gcc 3.4
and will likely continue to use that version.

Does this mean that we'll start to libgcc_s.dll's sprouting like
mushrooms in the install dirs of various apps, or in *gasp*
%WINDIR%/system32 over the coming years?  Is this library versioned at
all?  What about conflicts?

Sometimes it seems like when you kill one weed, five pop up to take its
place.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/