This is the mail archive of the
mailing list for the GCC project.
[ANNOUNCE] Libgcj relocation announce.
- To: java-announce at sources dot redhat dot com, gcc-announce at gcc dot gnu dot org
- Subject: [ANNOUNCE] Libgcj relocation announce.
- From: Alexandre Petit-Bianco <apbianco at cygnus dot com>
- Date: Sun, 5 Nov 2000 10:02:45 -0800
- Reply-to: apbianco at cygnus dot com
1) What we intend to do:
The libgcj/gcj team plans on moving the source code of the Java
run-time environment, called libgcj from its own source tree to Gcc's
source tree. We plan to do this by copying over the `,v' files from
the libgcj CVS repository to the gcc CVS repository. That will let us
preserve our extensive version history.
Because of uncleared licensing issues, libgcj has always been made
accessible as a separate source tree and Java hackers would first have
to build and install the proper compilers (gcj and c++) before
configuring and building the sources of their Java runtime.
But now that the licensing issues have be cleared, libgcj will be
moved to the base of the gcc tree and the Java run-time system will be
treated the same way other run-time sources (like libstdc++-v3 or
libchill) currently are. This will add four new directories to the
- libjava/, which contains over 1600 files, most of them are Java or
C++ files. This is our implementation of a Java run-time,
- boehm-gc/, which mostly consists of C files and implements Hans
Boehm's conservative garbage collector the Java run-time needs,
- libffi/, which contains C and assembly files and is used by the
Java interpreter implemented in libjava/,
- fastjar/, which contains a GPL'ed archive utility we need in order
to create our class file archive.
2) New faces
We will be giving write access to the libgcj/gcj repositories to the
krab:*****:9057:65530:Kresten Krab Thorup:/home/krab:/bin/bash
Bryce works everywhere libgcj/gcj need to be fixed, Kresten wrote our
interpreter. Bradley works on our web pages. Hans helped us with his
collector and ported libffi to IA-64. Mark hacks on the core classes,
Rolf hacks mostly on AWT classes.
3) How will this change your life?
How this will change your life depends on the extent of your interests
with Gcc and how you relate to the source tree.
- If you have no interested in Java, don't configure the toolchain
for Java support and you will never build the Java run-time pieces.
- If you are a maintainer of the compiler, especially a C++
maintainer, we encourage you to compile the Java run-time
environment as it depends on special and general C++ support to
build. It exercises your code in new ways and makes sure that your
C++ changes aren't breaking what Java relies on. If you change the
infrastructure of the compilers suite, building and testing the
Java run-time will let you know if you broke something in the Java
front-end. If you are a maintainer of one of the libraries libgcj
depends on, like libstdc++-v3, you should also build the Java
Libgcj features a minimal testsuite that should let you know if
something went horribly wrong. More ambitious testing can be done
using the Mauve test suite (http://sources.redhat.com/mauve/)
4) How are we trying to make sure that it will work.
We're experimenting with a merged tree as we speak. Before we
effectively move the sources, we plan on claiming build support for
the following platforms:
x86/Linux optionally testing Debian current stable and Red Hat distros
PPC/Linux Most likely LinuxPPC.org
We will also test a cross compiler; most likely a Linux or Solaris
hosted Tx39 toolchain.
5) What do you have to do to make it to work?
- Make sure you don't disable building the java compiler when you
configure your tree,
- There are two libgcj specific configure options you should consider
using `--enable-shared' and `enable-threads=posix'.
- From the toplevel of your build directory, `make' should build libgcj.
See the links below for more details.
We'll proceed when we're ready and when we have addressed people's
concerns regarding this operation. We plan on stabilizing the libgcj
tree first by disabling its write access and start building on the
selected platforms. We will perform adequate testing and then move the
repository over, preferably during a quiet day; most likely at the end
of a week-end.
7) Post merge management: inquiries, problem reports and contributions
After the merge occur, the libgcj/gcj team will respond to inquiries
and problem reports. The mailing list for this is `java-discuss', see
the mailing lists link below for details. We encourage people to file
problem reports into our GNATS database. If you wish to contribute
patches, please send them to the `java-patches' list.
8) Libgcj/Gcj resources.
The libgcj/gcj web pages are kept in a separate directory. Over time,
we plan to merge our web pages into the gcc pages. For now, the
libgcj/gcj web pages can be found at:
http://sources.redhat.com/java/mail.html Mailing lists
http://sources.redhat.com/java/build-snapshot.html Building libgcj
http://sources.redhat.com/java/libgcj-platforms.html Supported platforms
http://sources.redhat.com/java/faq.html#3_0 Build FAQs
The libgcj/gcj GNATS database:
You should use the `libgcj' category. Note that we haven't yet decided
how to address our separate Gnats database. We're reluctant to move
PRs into the gcc database as that would require renumbering. Suggestions
The libgcj/gcj team.