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
