This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: GCC-4.7.2-2: Go/No-go?
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin-apps at cygwin dot com
- Date: Thu, 11 Apr 2013 01:58:23 -0500
- Subject: Re: GCC-4.7.2-2: Go/No-go?
- References: <51643F10 dot 7000905 at gmail dot com> <87eheixuz8 dot fsf at Rainer dot invalid> <20130410154730 dot GA404 at ednor dot casa dot cgf dot cx> <516599BE dot 7090000 at gmail dot com> <51661EA2 dot 1070801 at users dot sourceforge dot net> <51665212 dot 6050101 at gmail dot com>
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