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 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.

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.

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

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.

   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.)

3.4 is EOL and should have been dropped long ago; we simply don't have the resources to support it ourselves. Just about any software that people are building today either works with recent 4.x or the distros have a patch for it.

   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.

   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?

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.

   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.

   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...



Yaakov


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