Re: GCC-4.7.2-2: Go/No-go?

["Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>]

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