Some notes on building gcc-4.3.0

[Charles Wilson]

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/