This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]