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