On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote: > On 2013-04-11 07:32, Dave Korn wrote: >> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote: >>> 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. > > Does it really, *really* matter? Perhaps not, but IMO it's the proper > thing to do for all arches, since the LTO plugin is just that, a plugin. > (If Apple were to still use GCC, it *would* matter, as there are > fundamental differences between Mach-O dylibs and bundles.)
Well, maybe I'll just wait until I get to a 4.8 release naturally and let it happen then. Or maybe I'll backport the patch for 4.7.3. I'll see how I feel at the time, since it's not /critical/ and I'd like to prioritise. >>> 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 usually recommend using cygport git master, and a number of maintainers > track it. I want to ship packages that the general public can rebuild using the standard distro really. Do you have any idea of a schedule for releasing these features? (Also, what is the "unversioned file format"?) >>> 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? > > No, it's not. In the cygport manual, [Definitions] should be treated as > readonly, and [Variables] can be altered. Huh? Cygport doesn't own CC any more than autotools if it's not being used. CC is a user variable. It belongs to make, and the make info page in the section on "Makefile Conventions" says that the user can substitute alternatives. Maintainers aren't the only people who use the compiler! >>> 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. > > You still haven't explained exactly what the problem is. You don't need > libgcj on the system in order to build a native gcc with java. Why would > the presence or lack of libgcj*.la make a difference? Ah, that's where our misunderstanding is. It's the presence of libstdc++.la that is required for libjava to build, not libgcj.la. That's because of a failure during linking (the awt peer IIRC) when libtool can't locate libstdc to link against. That in turn happens because it uses gcc.exe to link, not g++.exe, and that in turn happens because libtool is invoked with the CC tag, not CXX, and that in turn happens because the module is composed entirely of .c files and does not have any .cc files to trigger libtool's language detection to know that C++ is required. >>> 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? > > Because they cause more trouble than they're worth, e.g. necessitating > hacks such as fix-libtool-scripts-for-latest-gcc-runtimes.sh. This is a > good summary of some of the issues: > > https://lists.fedoraproject.org/pipermail/mingw/2012-January/004421.html Hmm. I need to digest that some more. I'm not entirely certain that it applies to the compiler runtime libs, because people often do use static linking against them when they want to make standalone executables. >>>> 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? > > We started with 4.3 using the static libgcc by default, then switched to > linking everything with -lgcc_s, then with 4.5 switched to doing so by > default only for DLLs (to minimize rebase errors iirc), and now we're going > back to shared across-the-board. I'm not complaining, and it seems like > the right thing to do, but it does evoke a sense of deja vu. Ah, I didn't remember that we'd taken a step back at one point during the process, I thought it had been a linear progression but that does ring a bell. Well, I'm sure now that it was the wrong way to try and solve the rebase problems, it's seriously incorrect to have two separate copies of the TLS variable control array or the EH table registration roots in a running program. cheers, DaveK
