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

[Yaakov (Cygwin/X)]

On 2013-04-11 23:24, Dave Korn wrote:
>> 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?

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.

>> 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!

*Within the scope of cygport*, cygport(1) is the "user" and it controls 
CC based on a number of factors.  CC can then be used within the 
cygport(5), e.g. with a handwritten makefile:

src_compile() {
	lndirs
	cd ${B}
	cygmake CC=${CC} CFLAGS="${CFLAGS}" AR=${AR} RANLIB=${RANLIB}
}

But like most cygport APIs, CC (and others marked as [Definitions] in 
the manual) should be treated as opaque constants; it might end up as 
gcc if building natively, or one of {i686,x86_64}-pc-cygwin-gcc if 
cross-compiling (cygport supports doing so from both Cygwin and Linux), 
${CROSS_HOST}-gcc if cross.cygclass is in use, or even clang or 
$host-clang with clang.cygclass.  Saying CC=gcc-4 obviously doesn't work 
in all those scenarios.

>> 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.

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.)

>> 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.

On the contrary, the compiler knows best how to links its own libs 
without libtool's help; in fact, sometimes libtool tries to be *too* 
smart and ends up just getting in the way, hence the need for patches 
such as this:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libtool;a=blob;f=2.4-pass-ldflags.patch;h=cd08a54;hb=HEAD

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?


Yaakov