Brian Dessent wrote:
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.
Well, 80% of compiled code out there is plain old C, so -static-libgcc
won't hurt that at all. If somebody wants to ship a C++ or Java binary,
then they will have two choices: (1) ship with the DLLs (2) use
-static-libgcc and don't throw exceptions. Ever. Especially when using STL.
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?
Yes. Microsoft does the same thing. They just have an inside advantage
in supplying their runtime with the OS.
They
will probably complain that they could get what they wanted from gcc 3.4
and will likely continue to use that version.
Ok. That doesn't worry me.
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?
Sadly, probably so. And it's worse than you know: because libgcc is not
built using libtool, it doesn't benefit from libtool's knowledge that
DLLs on cygwin should be called cyg*.dll. Thus, unless changes are
made, both mingw and cygwin will ship "libgcc_s.dll" files that users
will want to put in their $PATH -- only one relies on cygwin1.dll and
the other on msvcrt.dll.
Then, there's talk on the mingw list (and also here...) about dwarf2 vs.
sjlj. All of these dlls will be incompatible with each other. But
these are *platform* and *configuration* incompatibilities, not
*version* incompatibilities.
Is this library versioned at
all?
Sort of -- on ELF systems. In our case, no. However, *for a given
platform/configuration* the API is well-managed, in that only new
functions are ever added; old ones are never removed or changed (merely
obsoleted). So that's not really a problem.
What about conflicts?
See above. Don't despair; it's not as dire as it sounds. The trunk
*currently* doesn't build libgcc_s.dll with the special cyg* prefix --
because nobody has built it shared at all on win32, so the problem of
conflicting with mingw hasn't come up. Teaching the build system about
the cyg prefix is actually a fairly simple change.
The other is part policy, part implementation: suppose cygwin (or mingw)
ships both a dwarf2 and a sjlj compiler. Each one will provide runtime
dlls (libgcc_s, but also the libtool-built runtimes libstdc++,
libsupc++, libgfortran, etc etc). Under normal circumstances, you'd use
a different build/host/target:
configure target=i686-pc-cygwin-dw2 build=...dw2 host=...dw2
so they'd each get installed in separate directories. However the dlls
need to go into the main /bin/ so users can have a simple PATH -- so the
DLLs need different names.
That is, the dll names need to be sensitive to the target= specifier --
even tho the static libs and import libs should maintain their
"standard" names (otherwise we have to muck with the spec files and make
a lot of other intrusive changes).
So, you might have:
cyggcc_s_dw.dll << i686-pc-cygwin-dw2/4.3.0/libgcc_s.dll.a
cyggcc_s.dll (sjlj) << i686-pc-cygwin/4.3.0/libgcc_s.dll.a
cygstdc++-6_dw.dll << i686-pc-cygwin-dw2/4.3.0/libstdc++.dll.a
cygstdc++-6.dll << i686-pc-cygwin/4.3.0/libstdc++.dll.a
etc. In the libgcc case, we have to play games in libgcc/config/. In
the latter case...we need a new libtool/automake feature, I think.
Sometimes it seems like when you kill one weed, five pop up to take its
place.
Yep.
--
Chuck
--
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/
