Bug 163249 - Invoking javac through tools.jar fails on ia64
Invoking javac through tools.jar fails on ia64
Product: Fedora
Classification: Fedora
Component: java-1.4.2-gcj-compat (Show other bugs)
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2005-07-14 10:05 EDT by Gary Benson
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: gcc-4.0.1-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-02 10:36:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Gary Benson 2005-07-14 10:05:00 EDT
Description of problem:
Invoking javac through tools.jar fails on ia64, which breaks ant.  Invoking it
on the command-line works fine.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. java -classpath /usr/lib/jvm/java/lib/tools.jar com.sun.tools.javac.Main
Actual results:
Missing resource : org/eclipse/jdt/internal/compiler/batch/messages.properties
for locale en_US
Exception in thread "main" java.lang.ExceptionInInitializerError
   <<No stacktrace available>>
Caused by: java.util.MissingResourceException: Bundle
org.eclipse.jdt.internal.compiler.batch.messages not found
   <<No stacktrace available>>

Expected results:
Should print a usage message.
Comment 1 Gary Benson 2005-07-14 10:24:53 EDT
The missins stacktraces probably look something like this:

Missing resource : org/eclipse/jdt/internal/compiler/batch/messages.properties
for locale en_GB
Exception in thread "main" java.lang.ExceptionInInitializerError
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
   at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader)
   at java.lang.Class.forName(java.lang.String) (/usr/lib/libgcj.so.6.0.0)
   at com.sun.tools.javac.Main.Main() (Unknown Source)
   at com.sun.tools.javac.Main.main(java.lang.String[]) (Unknown Source)
   at gnu.java.lang.MainThread.call_main() (/usr/lib/libgcj.so.6.0.0)
   at gnu.java.lang.MainThread.run() (/usr/lib/libgcj.so.6.0.0)
Caused by: java.util.MissingResourceException: Bundle
org.eclipse.jdt.internal.compiler.batch.messages not found
   at java.util.ResourceBundle.getBundle(java.lang.String, java.util.Locale,
java.lang.ClassLoader) (/usr/lib/libgcj.so.6.0.0)
   at java.util.ResourceBundle.getBundle(java.lang.String, java.util.Locale)
   at org.eclipse.jdt.internal.compiler.batch.Main.relocalize() (Unknown Source)
   at org.eclipse.jdt.internal.compiler.batch.Main.<clinit>() (Unknown Source)
   at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.6.0.0)
   ...6 more
Comment 2 Gary Benson 2005-07-14 10:31:40 EDT
Hmmm, java.util.ResourceBundle.getBundle(String, Locale) (second down in the
stacktrace) looks like this:

  public static ResourceBundle getBundle(String baseName)
    ClassLoader cl = getCallingClassLoader();
    if (cl == null)
      cl = ClassLoader.getSystemClassLoader();
    return getBundle(baseName, Locale.getDefault(), cl);

I wonder, is getCallingClassLoader() failing for the same reason as that which
is causing the "<<No stacktrace available>>" messages?
Comment 4 Andrew Haley 2005-07-14 11:36:13 EDT
Try this test on IA-64.

#include <execinfo.h>
#include <stdio.h>
main (void)
  void *p[12];
  int NN = backtrace (p, 12);
  char **pp = backtrace_symbols (p, NN);
  printf ("trace: %d\n", NN);
  int i;
  for (i=0; i<NN; i++)
    printf (" %s \n", pp[i]);
Comment 5 Gary Benson 2005-07-14 11:46:30 EDT
natasha:[gbenson]$ ./backtrace.ia64
trace: 3
 ./backtrace.ia64 [0x4000000000000750]
 /lib/tls/libc.so.6.1(__libc_start_main+0x440) [0x200000000006a990]
 ./backtrace.ia64 [0x40000000000005a0]
Comment 6 Gary Benson 2005-07-15 08:52:07 EDT
Ok, so backtrace() was enabled on ia64 in libgcj-4.0.1-3, and ant successfully
built with it.  However, tools.jar still gives the "Missing resource" error if
eclipse-ecj.jar is native compiled.  I've renamed eclipse-ecj's database file on
the build machine to work around this.
Comment 7 Gary Benson 2005-08-25 07:18:29 EDT
There is a problem in tomcat5's build when native which could be this same
issue.  The class org.apache.jasper.JspC, loaded through ant's classloader,
throws an exception during <clinit> complaining that it can't find itself in the
system classloader.
Comment 8 Red Hat Bugzilla 2007-02-05 14:31:18 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Note You need to log in before you can comment on or make changes to this bug.