Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: JRuby 1.1b1
    • Fix Version/s: None
    • Component/s: IBM/Other VM
    • Labels:
      None
    • Environment:
      Debian sid, GCJ 4.2
    • Number of attachments :
      1

      Description

      When trying to build with GCJ 4.2, I get the following:
      generate-method-classes:
      [touch] Creating /home/seb/work/debian/jruby/1.1b1/jruby-1.1b1/build/__empty.rb
      [java] Exception in thread "main" java.lang.NoClassDefFoundError: org.jruby.RubyModuleInvoker$include_p_method_1_0
      [java] at java.lang.Class.initializeClass(libgcj.so.81)
      [java] at java.lang.reflect.Constructor.newInstance(libgcj.so.81)
      [java] at org.jruby.internal.runtime.methods.InvocationMethodFactory.getAnnotatedMethod(InvocationMethodFactory.java:379)
      [java] at org.jruby.RubyModule.defineAnnotatedMethod(RubyModule.java:471)
      [java] at org.jruby.RubyModule.defineAnnotatedMethods(RubyModule.java:458)
      [java] at org.jruby.RubyModule.createModuleClass(RubyModule.java:99)
      [java] at org.jruby.Ruby.initCoreClasses(Ruby.java:1276)
      [java] at org.jruby.Ruby.init(Ruby.java:1171)
      [java] at org.jruby.Ruby.newInstance(Ruby.java:322)
      [java] at org.jruby.Main.runInterpreter(Main.java:168)
      [java] at org.jruby.Main.run(Main.java:117)
      [java] at org.jruby.Main.main(Main.java:92)
      [java] Caused by: java.lang.VerifyError: verification failed at PC 82 in org.jruby.RubyModuleInvoker$include_p_method_1_0:call((Lorg.jruby.runtime.ThreadContext;Lorg.jruby.runtime.builtin.IRubyObject;Lorg.jruby.RubyModule;Ljava.lang.String;[Lorg.jruby.runtime.builtin.IRubyObject;Lorg.jruby.runtime.Block;)Lorg.jruby.runtime.builtin.IRubyObject: incompatible return type
      [java] at java.lang.Class.initializeClass(libgcj.so.81)
      [java] ...11 more

      1.0.2 built fine with GCJ, after the following patches were applied:

      diff -urNad jruby-1.1.0~/src/org/jruby/RubyZlib.java jruby-1.0.2/src/org/jruby/RubyZlib.java
      --- jruby-1.1.0~/src/org/jruby/RubyZlib.java    2007-11-01 08:32:20.000000000 -0700
      +++ jruby-1.1.0/src/org/jruby/RubyZlib.java     2007-11-06 13:17:51.000000000 -0800
      @@ -663,7 +663,7 @@
                   return orig_name == null ? getRuntime().getNil() : getRuntime().newString(orig_name);
               }
               
      -        public Object to_io() {
      +        public IRubyObject to_io() {
                   return realIo;
               }
               
      diff -urNad jruby-1.1.0~/src/org/jruby/compiler/impl/StandardASMCompiler.java jruby-1.0.2/src/org/jruby/compiler/impl/StandardASMCompiler.java
      --- jruby-1.1.0~/src/org/jruby/compiler/impl/StandardASMCompiler.java   2007-11-06 13:17:06.000000000 -0800
      +++ jruby-1.1.0/src/org/jruby/compiler/impl/StandardASMCompiler.java    2007-11-06 13:17:14.000000000 -0800
      @@ -289,7 +289,7 @@
               cv.visitField(ACC_STATIC | ACC_PRIVATE | ACC_FINAL, "$isClassLoaded", cg.ci(Boolean.TYPE), null, Boolean.FALSE);
               cv.visitField(ACC_STATIC | ACC_PRIVATE | ACC_FINAL, "$class", cg.ci(Class.class), null, null);
               
      -        SkinnyMethodAdapter mv = new SkinnyMethodAdapter(cv.visitMethod(ACC_PUBLIC, "<clinit>", cg.sig(Void.TYPE), null, null));
      +       SkinnyMethodAdapter mv = new SkinnyMethodAdapter(cv.visitMethod(ACC_PUBLIC | ACC_STATIC, "<clinit>", cg.sig(Void.TYPE), null, null));
               mv.start();
               
               // This is a little hacky...since clinit recurses, set a boolean so we don't continue trying to load class
      diff -urNad jruby-1.1.0~/src/org/jruby/libraries/ThreadLibrary.java jruby-1.0.2/src/org/jruby/libraries/ThreadLibrary.java
      --- jruby-1.1.0~/src/org/jruby/libraries/ThreadLibrary.java     2007-11-01 08:32:20.000000000 -0700
      +++ jruby-1.1.0/src/org/jruby/libraries/ThreadLibrary.java      2007-11-06 13:19:07.000000000 -0800
      @@ -249,7 +249,7 @@
                   return RubyNumeric.int2fix(getRuntime(), entries.size());
               }
       
      -        public int num_waiting() { return 0; }
      +        public IRubyObject num_waiting() { return getRuntime().newFixnum(0); }
       
               public synchronized IRubyObject pop(IRubyObject[] args) {
                   boolean should_block = true;
      

        Activity

        Hide
        Sebastien Delafond added a comment -

        Hrm, the patch above looks completely messed up, so I'm attaching it instead.

        Show
        Sebastien Delafond added a comment - Hrm, the patch above looks completely messed up, so I'm attaching it instead.
        Hide
        Charles Oliver Nutter added a comment -

        In the interest of moving this forward, I'm going to mark it resolved, since the issues fixed by the patch have already been fixed on both 1.0 branch and trunk. I don't have GCJ available to test on, but if there are additional problems please report new bugs for them and we'll try to get them tidied up.

        Show
        Charles Oliver Nutter added a comment - In the interest of moving this forward, I'm going to mark it resolved, since the issues fixed by the patch have already been fixed on both 1.0 branch and trunk. I don't have GCJ available to test on, but if there are additional problems please report new bugs for them and we'll try to get them tidied up.
        Hide
        Charles Oliver Nutter added a comment -

        Migrating bugs marked as resolved before 1.1RC3 and tagged as version 1.1 as fixed in RC3. Only two bugs are actually fixed between RC3 and 1.1

        Show
        Charles Oliver Nutter added a comment - Migrating bugs marked as resolved before 1.1RC3 and tagged as version 1.1 as fixed in RC3. Only two bugs are actually fixed between RC3 and 1.1
        Hide
        Sebastien Delafond added a comment -

        18:20:08 Seb | should I reopen JRUBY-1542, as it is actually not fixed ?
        18:20:11 Seb | or do we not care ?
        18:20:42 Seb | I'm writing a short progress report on why jruby1.1 isn't in debian yet, and was gonna refer to that bug so people can read about how/why it doesn't build with gcj, but I noticed it has been closed :>
        18:25:55 <anonymous> | I'd think that gcj is pretty low in priority now that openjdk is available in most distros
        18:43:04 kmeyer | <anonymous>: except for on ppc, openjdk only runs in interpreted mode
        18:43:06 kmeyer | which is painful.,
        18:43:26 kmeyer | Seb: please, a vote for running on gcj is good for me too.
        18:44:05 <anonymous> | I forgot about non-x86
        18:45:29 kmeyer | people tend to
        18:49:42 <anonymous> | apart from sparc, most non-x86 arches these days are only used in embedded stuff
        18:49:51 <anonymous> | so they're not on the radar
        18:54:57 Seb | kmeyer: heh
        18:55:01 Seb | so the crowd is mixed
        18:58:23 kmeyer | eh, there are plenty of macs lying around
        19:03:14 Seb | i'm all for re-opening it, but ... :>
        19:03:47 Seb | i can totally understand why it's low priority, but the fact it's closed gives the wrong impression (namely that 1.1 can be built with gcj, which is not the case)
        19:03:52 kmeyer | right.
        19:03:54 kmeyer | re-open it.
        19:04:22 kmeyer | it can't build on gcj (AFAIK) and also jna can't build on gcj
        19:04:28 kmeyer | the rest can, IIRC
        19:04:43 kmeyer | (jna-posix, joda-time, jvyamlb, bytelist, etc)

        Show
        Sebastien Delafond added a comment - 18:20:08 Seb | should I reopen JRUBY-1542 , as it is actually not fixed ? 18:20:11 Seb | or do we not care ? 18:20:42 Seb | I'm writing a short progress report on why jruby1.1 isn't in debian yet, and was gonna refer to that bug so people can read about how/why it doesn't build with gcj, but I noticed it has been closed :> 18:25:55 <anonymous> | I'd think that gcj is pretty low in priority now that openjdk is available in most distros 18:43:04 kmeyer | <anonymous>: except for on ppc, openjdk only runs in interpreted mode 18:43:06 kmeyer | which is painful., 18:43:26 kmeyer | Seb: please, a vote for running on gcj is good for me too. 18:44:05 <anonymous> | I forgot about non-x86 18:45:29 kmeyer | people tend to 18:49:42 <anonymous> | apart from sparc, most non-x86 arches these days are only used in embedded stuff 18:49:51 <anonymous> | so they're not on the radar 18:54:57 Seb | kmeyer: heh 18:55:01 Seb | so the crowd is mixed 18:58:23 kmeyer | eh, there are plenty of macs lying around 19:03:14 Seb | i'm all for re-opening it, but ... :> 19:03:47 Seb | i can totally understand why it's low priority, but the fact it's closed gives the wrong impression (namely that 1.1 can be built with gcj, which is not the case) 19:03:52 kmeyer | right. 19:03:54 kmeyer | re-open it. 19:04:22 kmeyer | it can't build on gcj (AFAIK) and also jna can't build on gcj 19:04:28 kmeyer | the rest can, IIRC 19:04:43 kmeyer | (jna-posix, joda-time, jvyamlb, bytelist, etc)
        Hide
        Charles Oliver Nutter added a comment -

        Maybe can do this in one of the maintenance releases, but without an apt (annotation processing tool) in GCJ it's kinda dead in the water.

        Show
        Charles Oliver Nutter added a comment - Maybe can do this in one of the maintenance releases, but without an apt (annotation processing tool) in GCJ it's kinda dead in the water.
        Hide
        Charles Oliver Nutter added a comment -

        GCJ 4.2 doesn't support any Java 5 APIs as far as I know, so it's going to be nearly impossible to support it in JRuby 1.1+ which all depend on Java 5. I don't see any reason we couldn't try to support a newer GCJ that works with Java 5 stuff, but with OpenJDK now getting into all Linux distros there's a lot less motivation to do so.

        Show
        Charles Oliver Nutter added a comment - GCJ 4.2 doesn't support any Java 5 APIs as far as I know, so it's going to be nearly impossible to support it in JRuby 1.1+ which all depend on Java 5. I don't see any reason we couldn't try to support a newer GCJ that works with Java 5 stuff, but with OpenJDK now getting into all Linux distros there's a lot less motivation to do so.
        Hide
        Sebastien Delafond added a comment -

        I agree, OpenJDK solved all the problems I was facing when packaging JRuby for Debian. Thank you for being extremely responsive on those issues, I really appreciated it!

        Show
        Sebastien Delafond added a comment - I agree, OpenJDK solved all the problems I was facing when packaging JRuby for Debian. Thank you for being extremely responsive on those issues, I really appreciated it!

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Sebastien Delafond
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: