GCC-4.7.2-2: Go/No-go?
Yaakov (Cygwin/X)
yselkowitz@users.sourceforge.net
Thu Apr 11 23:28:00 GMT 2013
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.)
>> 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.
>> 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.
>> 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?
>> 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
>>> 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.
Yaakov
More information about the Cygwin-apps
mailing list