X-Spam-Check-By: sourceware.org Message-ID: <46736405.2010303@cwilson.fastmail.fm> Date: Sat, 16 Jun 2007 00:16:05 -0400 From: Charles Wilson User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Some notes on building gcc-4.3.0 References: <466F9B52 DOT 1000709 AT cwilson DOT fastmail DOT fm> <4672C1F4 DOT 6010306 AT users DOT sourceforge DOT net> In-Reply-To: <4672C1F4.6010306@users.sourceforge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/