On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 11:56, Dave Korn wrote:
>> It takes 11 hours on a triple-core machine at -j6 to build and
>> package GCC.
>> In order to guarantee consistent reproduction I always respin the built
>> package from -src package through two generations. It then takes
>> three to
>> five days to run enough of the testsuite to be confident that the
>> packaged
>> compiler works well. So it'd be next week at the earliest.
>
> While your diligence is admirable, I think some common sense review can
> be used here, as only one of my patches actually affects the compiler
> itself, and even then only the specs. I'm not exactly messing around
> with code generation here.
Yes, I've looked at most of your patches already, I'm not saying there's any
complication in adding them, it's just that I didn't want to wait another
howevermany days before getting 4.7.2-2 out there. I'll put them all into the
next release, which I'll get on with pronto.
> BTW, in your absence, it was agreed that gcc3 should go away and that
> gcc4 should be *the* gcc in the distro. This will simplify the build
> and drop the dep on 'alternatives'. Can this get into the next release?
Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using
it and wants to know where it's gone. (I suppose if that happens I could
always consider rolling a gcc3 package with all -3 suffixed executables.)
I'll need to make sure not to lose the cc.exe -> gcc.exe symlink, and it
might be useful for backward-compatibility to provide a bunch of -4 suffixed
links to the other executables for people who've written CC=gcc-4 in their
Makefiles, but that can be done with just ln rather than using alternatives.
> I don't understand why there's a libquadmath0-devel; like the other C
> libraries, this should just be part of gcc-core.
Hmm. I got the impression that libquadmath could stand alone, i.e. be
useful in a non-GCC context, but I guess not or it would be installing its
include files into /usr/include rather than the GCC private include dir. I'll
merge it into gcc-core in the next release as you suggest.
> This was only
> necessary for libstdc++, and only so long as .la files were included.
> IIRC we agreed to remove them, but your reason for not doing so in the
> .cygport isn't clear to me.
Without the .la files, libjava doesn't build. And in general I don't want
to second-guess the compiler: since the upstream makefiles think it's
important to install them, so do I.
> Also, could you please explain the reasons for the ehdebug, execstack,
> and shared-libgcc patches?
ehdebug: When we first switched from sjlj to dw2 exceptions, there were so
many corner case bugs that kept cropping up across multiple releases that I
wanted to hang onto the debugging code. During development the debugging
output was under control of a variable that I replaced by a #define 0 just
before the release. It's obsolete now, I'll drop it, but it was incredibly
useful for the first few gcc4 releases.
execstack: Trampolines need an executable stack. DEP on recent Windows OSs
marks the stack non-executable; this option allows the stack to be set
executable during the runtime startup, without having to disable DEP for the
entire process. Think I may have inherited it from Danny Smith. Mingw has it
upstream, I'll get it committed there for Cygwin too.
shared-libgcc: Makes linking against shared libgcc the default for all
executables; previously it was only on by default for DLLs. Vital for
importing TLS variables from DLLs, upstream since 4.8.0.
cheers,
DaveK
