This is the mail archive of the
mailing list for the Cygwin project.
Re: Some notes on building gcc-4.3.0
Yaakov (Cygwin Ports) wrote:
First, I had to massage the tree in the following ways (and I was using
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
(furthermore, given the ~700MB svn directory, I'm thinking cygport's
focus on "unpack this tarball" -- or, in this context,
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
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
Nope, no such luck:
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)
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
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
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
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
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)
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html