Some notes on building gcc-4.3.0

[Charles Wilson]

Yaakov (Cygwin Ports) wrote:

>> First, I had to massage the tree in the following ways (and I was using
>> revision 125636):
> 
> Out of curiosity, have you done this with cygport yet?

No: it would impose too heavy a burden on my already overloaded plate. 
I'm using an alternate prefix (/opt) because I don't want to clobber my 
working gcc -- but cygport doesn't support prefixes other than /usr.

I could patch cygport to add that functionality, but I've learned my 
lesson there.


(furthermore, given the ~700MB svn directory, I'm thinking cygport's 
focus on "unpack this tarball" -- or, in this context, 
just-this-once-download-the-repo-then-make-a-tarball-but-strip-the-.svn-dirs, 
thus ensuring that you can never 'svn update' and that "just-this-once" 
is really "over and over again" -- would not win me any friends at gcc.org)

That model works okay with less active projects (where you don't need to 
sync as much) or much much smaller projects (like libtool).  But it's 
not a good fit for gcc.  The difference between gcc and your massive KDE 
and/or gnome releases, is that you can pretty much treat each individual 
library or subproject separately.  Gcc is basically a 
build-it-all-at-once kind of thing.

That's ok.  cygport -- or at least, my local version of -- solves many, 
even most, of the issues I've seen with maintaining/porting/compiling 
software on cygwin.  It never will solve them all -- but it isn't the 
only tool in the toolbox, and that's fine.

> Interesting.  I wonder if this would help with linking libsmokekde and
> libkdejava, both of which fail during linking for the same reason.
> Perhaps the other compilers should also be built with this flag for the
> same reason (and binutils' ld as well)?

Well, 100MB is _really_ a lot of stack space.  That was just the number 
that Dave Korn threw out on the gcc list.  It was "big enough" -- but 
maybe 20M would be, also; nobody has done that analysis.  And for 
multithreaded apps, you're talking 100MB /for each thread/. 
Fortunately, cc1 and jc1 are NOT multithreaded -- so you could probably 
get away with it (unless you want to compile libjava natively on your 
WinCE handheld...)

However, I wonder if the real issue is just that somebody stupidified 
dbxout.c so that it is recursing a lot more than it should, or is 
allocating really big stuff on the stack.  '-Wl,stack 100MB' smells like 
a workaround to me, and not a very good one.

> - From your notes, I gather that all libs are being built shared.  If so,
> that's very good news, and I look forward to seeing this become readily
> available.

Nope, no such luck:
     ...
     --with-arch=i486 \
     --with-tune=i686 \
     --disable-werror \
     --disable-shared

I've got a patch in the works that
   (a) successfully builds libgcc and libstdc++ shared
   (b) but any test app built using those dlls dies horribly.
So, there's some work left to do (Danny himself uses an out-of-tree 
procedure, taking the existing .a's and turning them into .dlls.  I have 
NEVER gotten that to work properly; perhaps I'm buying my sacrificial 
chickens from the wrong vendor)

> To that end, a few questions:
> 
> 1) What progress is being made to get these patches included upstream?

Well, Danny's dwarf2 stuff just went in this week. The other stuff -- 
I'm not sure: none of it is mine, and some of them are workarounds (e.g. 
the libstdc++ pr24196 thing would be better solved by getting shared 
runtimes, OR one could simply configure with 
--enable-fully-dynamic-string instead.  So, it's unlikely that patch 
would be accepted, since it disimproves behavior for all other (sane) 
platforms.

Worse, gcc is going into code freeze -- with the exception of merges 
from a few major project branches -- for a few weeks, starting today or 
tomorrow. This is specifically to stabilize the tree in light of those 
major project merges.  Once that's done, then Mark is going to close 
"stage 1"...

I'm not sure if the "enable build shared on cygwin/mingw" is stage-2 
material. It's certainly not ready _now_ -- so if it isn't stage-2, then 
it must wait 'til 4.4.

> 2) How long before gcc-4.3 will be stabilized enough to be generally usable?

Your guess is as good as mine -- as I said, Mark is closing stage-1 Real 
Soon Now; and stage-1 has been over eight months long (instead of the 
planned two) so that's good news for stability-in-the-near-future on 
most platforms.  However, since getting performance and features 
equivalent to or better than the existing cygwin-gcc-3.4.x-special and 
mingw-gcc-3.4.x-special releases will require additional work, I don't 
know if that "additional work" will (a) get done in time for the 
eventual 4.3 release, or (b) be accepted into the tree during stage-2 or 
stage-3 development.


While the testsuite converage on cygwin looks pretty good (given that 
only static runtimes are built), IMO there is one big -- huge -- 
regression in 4.2/4.3 with regards to the currently-shipping cygwin-gcc 
and mingw-gcc:
    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.

[*] Note that official GNU gcc releases NEVER supported this; it was 
always an out-of-tree patch applied by both the mingw and cygwin 
maintainers. Unfortutely, that patch is not a good fit for the 4.x 
internal architecture (see Official Way Forward, above).


> 3) Could you and/or others working on this keep this list updated on
> further progress?

If I learn something of interest to the cygwin community, or make 
significant progress, I'll certainly keep the list informed.  Things 
have really been shakin' the last few months, with
   (1) finally cygwin-friendly libtool merged in (with attendant
       autoconf and automake updates)
   (2) Danny's DWARF2 stuff
   (3) The official gnu release of gcc-4.2 has spurred the mingw guys
       to look once again at the toolset (they deliberately gave the
       4.0 and 4.1 releases a pass)

--
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/