libgcj-2.95 Platform Test Strategy

Platform Coverage

One of the critical steps in making releases is platform testing. Since there is no prior release of libgcj to perform regressions against, we want to compare results against a known building platform, i686-pc-linux-gnu.

We would like to get the widest coverage possible, so please check the following chart for platforms that have already been covered if you have a choice of platforms to build upon.

Please send build/test results (in the format described below) to java@gcc.gnu.org.
You may also address questions to java-discuss or to indicate that you would like to help in another way with some phase of the libgcj-2.95 release cycle.

How to run the tests

First, you must have built and installed libgcj using the libgcj-2_95-branch branch of the source.

This can be done by including the '-rlibgcj-2_95-branch' flag on the 'cvs co' command line or downloading the snapshot and then following the build instructions on the libgcj page. (For those developers downloading via snapshots, please note that the snapshoting process has been temporarily changed to use the libgcj-2_95-branch rather than the main trunk. Please be aware of this if you are looking for patches that get applied to the main source tree but not to the branch).

Next, go to the libjava/testsuite directory of your build tree and run 'make check' after doing the following:

  • In order to more fully exercise libgcj, it is highly recommended to include the Mauve testsuite in the test run.
    The Mauve tests are available for download via both anonymous cvs and snapshots.
  • The env variable MAUVEDIR must be set to the top of the Mauve source tree.
  • The testsuites rely on the dejagnu package. You can download the current dejagnu snapshot from gcc. Please note that some earlier versions of dejagnu are missing a patch that's in recent snapshots. Please make sure you have tried running the testsuites with the current snapshot of dejagnu before reporting any testsuite platform problems. There is a short entry in the gcc FAQ if you would like more information about this issue.

Testing notes

  • By default, tests that first compile to bytecode use an installed javac program. Set the environment variable JAVAC to 'gcj -C' to use the installed gcj for this purpose.
  • It is highly recommended that you not override the default libgcj configuration option for building with dynamic libraries. This is to avoid having to explicitly specify some libgcj object modules on the link line to get certain java/net Mauve tests to execute.
  • An gcc patch affecting gcj was made on 24-June-99. Developers using cvs to access the gcc source should update an rebuild to get that fix. The next gcc snapshot with this patch will not be available until 30-June-99. At that point developers without cvs access should download that patch. In the meantime, the problem can be avoided in test runs with the following RUNTESTFLAGS options:
       make RUNTESTFLAGS='GCJ_UNDER_TEST="gcj -L/x2/java/build/i686-pc-linux-gnu/libjava"' \
       JAVAC='gcj -C -I/x2/java/build/i686-pc-linux-gnu/libjava/libgcj.zip' \
       GCJ_UNDER_TEST='gcj -L/x2/java/install/lib' check
      
    i.e. GCJ_UNDER_TEST needs a -L pointing to the libjava build directory and JAVAC needs a -I pointing to the zip file.

Current Platform Testing Status

This is the current results for the platforms reported to us. Please use this format when reporting your results.

Platform Configuration Build Status Test Results
i686-pc-linux-gnu --enable-threads=posix OK # of expected passes 1876
# of unexpected failures 32
# of expected failures 6
alphapca56-unknown-linux-gnu --enable-threads=posix
--enable-fast-character
--enable-java-gc=boehm
OK # of expected passes 187
# of unexpected failures 19
# of expected failures 18
sparc-sun-solaris2.6 OK # of expected passes 60
# of unexpected failures 68
# of expected failures 96
sparc-sun-solaris2.7 --enable-java-gc=no OK # of expected passes 196
# of unexpected failures 22
# of expected failures 8

A list of deviations from the posted baseline list of test results should follow any entry you submit. A context diff is fine if it is clear what tests are failing; we'd rather not have to deal with a complete output listing unless it is necessary to comprehend the deviations.

Note that if you are not using POSIX threads, some tests will not complete successfully, so differences should be expected.

Please send build/test results to java@gcc.gnu.org in this format.

Submitting Patches

libgcj-2.95 should be considered frozen except for low-risk porting changes that increase coverage to new target platforms (i.e. those changes that would not affect other platforms). High priority changes will be determined and considered on a case by case basis. All other changes will only go into the main trunk and not the libgcj-2_95-branch.

The mailing list, java-patches@gcc.gnu.org has been created for patch submissions. We plan to use this list just as gcc uses the gcc-patches list: all patches will be sent to the list. If you have a patch you want considered, please send it there along with an explanation and a ChangeLog entry.

Developers with checkin-after-approval access should also send patches to this list, and then check them in after approval is given. Developers with direct checkin access should also send patches to this list; this can happen concurrently with the checkin.

Some discussion will probably take place on this list (just as with gcc-patches). The web page has subscription info, as well as a link to the archives.

The java-patches mailing list is for patches to the libgcj code (libjava, boehm-gc, zlib, etc) code only. In particular, compiler patches still have to go through gcc, so please don't send them to java-patches.

GCJ

GCJ Home
GCC Home
Status
FAQ
Documentation
Contributing
Done with GCJ

About GCC
Mission Statement
Releases
Snapshots
Mailing lists
Contributors
Steering Committee
Documentation
Installation
· Platforms
· Testing
Manual
FAQ
Wiki
Further Readings
Download
Mirror sites
Binaries
"Live" Sources
SVN read access
Rsync read access
SVN write access
Development
Development Plan
· Tentative Timeline
Contributing
Why contribute?
Open projects
Front ends
Back ends
Extensions
Benchmarks
Bugs
Known bugs
How to report
Bug database
· Management