This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: GCC-4.7.2-2: Go/No-go?
- From: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 12 Apr 2013 18:34:45 +0100
- Subject: Re: GCC-4.7.2-2: Go/No-go?
- References: <51643F10 dot 7000905 at gmail dot com> <87eheixuz8 dot fsf at Rainer dot invalid> <20130410154730 dot GA404 at ednor dot casa dot cgf dot cx> <516599BE dot 7090000 at gmail dot com> <51661EA2 dot 1070801 at users dot sourceforge dot net> <51665212 dot 6050101 at gmail dot com> <51665F0F dot 8040902 at users dot sourceforge dot net> <5166AD45 dot 8080809 at gmail dot com> <5167472D dot 1040500 at users dot sourceforge dot net> <51678C7A dot 9040901 at gmail dot com> <5167E573 dot 8050107 at users dot sourceforge dot net>
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