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


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/


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