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 11:44, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 23:24, Dave Korn wrote:

> Most of the discussed features are already in the latest release.  Right 
> now, the major difference between the release and git master is full 
> support for x86_64-pc-cygwin, but there are a number of other bugfixes and
> enhancements.  I hope to cut a release from master as early as next week.
> 
>> (Also, what is the "unversioned file format"?)
> 
> Where the file is named foo.cygport and NAME/VERSION/RELEASE are defined 
> inside of the cygport(5) instead of deriving these from the filename as 
> before.  My gcc.cygport is an example of this, as well as the use of 
> setup.hint generation.

  Great, then I'll take full advantage of the new stuff.

>> 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!
> 
> *Within the scope of cygport*, cygport(1) is the "user" and it controls CC
> based on a number of factors.
        [ ... ]
> Saying CC=gcc-4 obviously doesn't work in all those scenarios.

  Well, yes, but we're talking here about whether I should leave a symlink
called gcc-4.exe in /usr/bin for the benefit of any end users who might have
makefiles (or other scripts) that aren't in any way related to cygport at all,
so none of that is relevant.

>>> 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.
        [ ... ]
> Oh, now I get it.  What *really* happened is that last time you tried this,
> you still had GNOME .la files on your system, some of which contained
> references to libstdc++.la because of the then-embedded copy of harfbuzz in
> the Pango libraries.  So when you installed an .la-less gcc then rebuilt
> gcc, the link failed because of the remaining libstdc++.la references in
> libgtkpeer's many (sub)deps; the same would have happened building *any*
> GTK+/GNOME package with libtool.
> 
> This would have worked even then if you had run the 
> fix-libtool-scripts-for-latest-gcc-runtimes.sh script with my modifications
> thereto (Ports gcc commit 00c6f36) immediately after installing the
> .la-less gcc.  In any case, the current versions of the GNOME libraries do
> not include .la files, so you won't have this problem with rebuilding gcc.
> (You should still run the modified script in any case.)

  Ah, thanks for the explanation.  That makes sense to me.

> Don't get me wrong, libtool is still the best option for building libraries
> portably, but it does not need .la files on the system to do so with shared
> libraries.  Now that we've figured out what the problem really was, and
> that it doesn't exist anymore, could we drop them from the next release?

  Absolutely, assuming nothing goes wrong when I test it.

  I should still package the updated version of
fix-libtool-scripts-for-latest-gcc-runtimes.sh and invoke it postinstall for
the benefit of any other .la files that are still on the system, right?

    cheers,
      DaveK


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