This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC-4.7.2-2: Go/No-go?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]