This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Some notes on building gcc-4.3.0

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
circumstances.  Not that this is any different on Linux, where apps that
want to throw/catch 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 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


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]