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


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