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 07:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
>> 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.
> 
> Your boehm-gc patch can replace my java-libgc-win32.patch, provided it 
> works properly.

  It appears to, libjava testsuite results are as good as they've ever been,
although I don't know whether or not the testsuite checks the invocation API.
 It's certainly the more complete approach to take than just not supporting
the register/unregister methods, as confirmed by the fact that upstream
boehm-gc has implemented it for Cygwin.

> libitm needs some more work before enabling, at least on x86_64 due to weak
> symbol and sysv_abi assumptions (I have managed to get statically-linked
> executables to work, but not DLL-linked ones); on i686 it *might* actually
> work with just my patch (the one in 4.8 branch is better), but in the
> interest of time this should probably wait for a future release.

  I'll try it and see how the test results look.

> Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies
> to 4.7 as well.

  I'll take a look for that.  Does it really matter?  I don't suppose we need
support swapping LTO plugins between different versions of the compiler, it's
totally a for-internal-use-only thing.

> Something else you missed: cygport supports a new, unversioned file format,
> and creates setup.hint files, including dependency detection.  I suggest
> using git master right now.

  Wouldn't that mean that the -src package I ship won't rebuild with the
version from the standard distribution?

>> 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.
> 
> That was never right, CC isn't supposed to be (ab)used like that.  I don't
> mind not supporting that going forward.

  Well it's not exactly any trouble so I may as well do it.  If you're not
using autotools, CC is yours to do what you like with isn't it?

>> 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.
> 
> How could removing the .la files during postinstall affect building libjava
> beforehand?

  Heh, of course not, I'm not suggesting time travel!  I should have said
*re*build: without the .la files installed on the user's system, the -src
package fails to rebuild.  I imagine (but didn't test) that applies to
building plain upstream SVN/tarball as well.

> As for the makefiles installing the .la files, upstream isn't "choosing" to
> do so, that's just how libtool works.  Some Linux distros, including 
> Fedora, have been removing them from all binary packages (except when they
> are needed by lt_dlopen() and friends), and for very good reason.

  What's the very good reason?

>> 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.
> 
> Should this be used on x86_64 as well?  The libgcc/config.host hunk of your
> patch only mentions ix86.

  I don't know for sure, not being familiar with 64-bit world yet, but would
imagine so.

>> 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.
> 
> Here we go again...

  Huh?

    cheers,
      DaveK


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