Loading ...
Sorry, an error occurred while loading the content.
 

Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

Expand Messages
  • Sébastien Lorquet
    when it s related to the dynamic library loader, TLS is thread local storage. (I m quite sure it s not Transport Layer Security :-) ) TLS is a mean to have
    Message 1 of 19 , Apr 8, 2009
      when it's related to the dynamic library loader, TLS is thread local storage. (I'm quite sure it's not Transport Layer Security :-) )
      TLS is a mean to have variables that are specific (or local) to a thread. when a tls variable is declared, it is available in all threads but its value is local to the thread, ie two threads can hold different values, and this is transparent to the programmer.

      I guess the java program you want to run is multithreaded and jamvm uses thread local storage to manage individual threads states, for example.

      I wanted to test jamvm this morning as my slug is on slugosbe 5.3, but I have a problem with the usb controller, and I can't install jamvm in the internal flash, there's not enough room :(

      Sebastien.

      On Wed, Apr 8, 2009 at 2:34 PM, Jan <obiyawn@...> wrote:

      Thanks. At this point I need to ask: What is TLS? Or is my slug really asking for a bit of TLC? ;-)

       

      From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On Behalf Of Sébastien Lorquet
      Sent: Wednesday, April 08, 2009 8:31 AM


      To: nslu2-linux@yahoogroups.com
      Subject: Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

       

      If ld.so does not support TLS, then I suppose you need a ld.so that supports TLS :)

      An option should be to upgrade this particular spark plug from the same one of another distribution, but it sounds a bit dangerous to me.

      Sebastien

      On Wed, Apr 8, 2009 at 2:02 PM, Jan Stanger <jan.stanger@...> wrote:

      Thanks for this suggestion. But it sounds more like replacing the engine of a car if all it takes is changing the spark plugs. SlugOS 3.10 has been running without a hitch for the last 2+ years on my NSLU2, and if not being able to run Java programs on it is the only drawback, then I will probably live with it (for now). J

       

      Perhaps there is another and simpler way to fix this (hint: spark plugs)? J

       

      Thanks

      -J

       

       

      From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On Behalf Of Sébastien Lorquet
      Sent: Wednesday, April 08, 2009 1:42 AM
      To: nslu2-linux@yahoogroups.com
      Subject: Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

       

      The first suggestion would be to drop slugos 3.10 and use Slugos 5.3 from http://www.slug-firmware.net/ (you'll notice that SlugOS 3 is release N-2 :) )
      After this, you may find that some bugs were resolved :)

      On Wed, Apr 8, 2009 at 5:28 AM, obi_jan <nslu2-linux@...> wrote:

      Hello!

      I was following the instructions on this page here to install Java on my NSLU2 under SlugOS 3.10: http://www.dpembo.ukfsn.org/2008/08/28/java-compiler-vm-on-the-nslu2/

      However, when I call 'jamvm', this error message appears:

      root@FileServer:~# jamvm
      ld.so does not support TLS, but program uses it!

      What a shame, I really wanted to run VideoLANs VLMa web interface: http://www.videolan.org/vlma/doc/setup.html

      Any suggestions?
      -J




      ------------------------------------

      Yahoo! Groups Links

      <*> To visit your group on the web, go to:
         http://groups.yahoo.com/group/nslu2-linux/

      <*> Your email settings:
         Individual Email | Traditional

      <*> To change settings online go to:
         http://groups.yahoo.com/group/nslu2-linux/join
         (Yahoo! ID required)

      <*> To change settings via email:
         mailto:nslu2-linux-digest@yahoogroups.com
         mailto:nslu2-linux-fullfeatured@yahoogroups.com

      <*> To unsubscribe from this group, send an email to:
         nslu2-linux-unsubscribe@yahoogroups.com

      <*> Your use of Yahoo! Groups is subject to:
         http://docs.yahoo.com/info/terms/

       

       

       




    • Jan
      Sebastien, Thanks for the elaborate explanation. Once you have your USB issues sorted, it would be great if you could try jamvm on 5.3 then. The error message
      Message 2 of 19 , Apr 8, 2009

        Sebastien,

         

        Thanks for the elaborate explanation. Once you have your USB issues sorted, it would be great if you could try jamvm on 5.3 then. The error message occurs even when I run jamvm without any parameters at all, meaning that I am not even asking it to run any Java byte code.

         

        I wonder what potential issues could result if I replace ld.so with a newer version. And where would I be able to obtain a newer version?

         

        Thanks

        Jan

         

        From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On Behalf Of Sébastien Lorquet
        Sent: Wednesday, April 08, 2009 8:55 AM
        To: nslu2-linux@yahoogroups.com
        Subject: Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

         

        when it's related to the dynamic library loader, TLS is thread local storage. (I'm quite sure it's not Transport Layer Security :-) )
        TLS is a mean to have variables that are specific (or local) to a thread. when a tls variable is declared, it is available in all threads but its value is local to the thread, ie two threads can hold different values, and this is transparent to the programmer.

        I guess the java program you want to run is multithreaded and jamvm uses thread local storage to manage individual threads states, for example.

        I wanted to test jamvm this morning as my slug is on slugosbe 5.3, but I have a problem with the usb controller, and I can't install jamvm in the internal flash, there's not enough room :(

        Sebastien.

        On Wed, Apr 8, 2009 at 2:34 PM, Jan <obiyawn@...> wrote:

        Thanks. At this point I need to ask: What is TLS? Or is my slug really asking for a bit of TLC? ;-)

         

        From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On Behalf Of Sébastien Lorquet
        Sent: Wednesday, April 08, 2009 8:31 AM


        To: nslu2-linux@yahoogroups.com
        Subject: Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

         

        If ld.so does not support TLS, then I suppose you need a ld.so that supports TLS :)

        An option should be to upgrade this particular spark plug from the same one of another distribution, but it sounds a bit dangerous to me.

        Sebastien

        On Wed, Apr 8, 2009 at 2:02 PM, Jan Stanger <jan.stanger@...> wrote:

        Thanks for this suggestion. But it sounds more like replacing the engine of a car if all it takes is changing the spark plugs. SlugOS 3.10 has been running without a hitch for the last 2+ years on my NSLU2, and if not being able to run Java programs on it is the only drawback, then I will probably live with it (for now). J

         

        Perhaps there is another and simpler way to fix this (hint: spark plugs)? J

         

        Thanks

        -J

         

         

        From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On Behalf Of Sébastien Lorquet
        Sent: Wednesday, April 08, 2009 1:42 AM
        To: nslu2-linux@yahoogroups.com
        Subject: Re: [nslu2-linux] jamvm (Java VM) on SlugOS ==> "ld.so does not support TLS, but program uses it"

         

        The first suggestion would be to drop slugos 3.10 and use Slugos 5.3 from http://www.slug-firmware.net/ (you'll notice that SlugOS 3 is release N-2 :) )
        After this, you may find that some bugs were resolved :)

        On Wed, Apr 8, 2009 at 5:28 AM, obi_jan <nslu2-linux@...> wrote:

        Hello!

        I was following the instructions on this page here to install Java on my NSLU2 under SlugOS 3.10: http://www.dpembo.ukfsn.org/2008/08/28/java-compiler-vm-on-the-nslu2/

        However, when I call 'jamvm', this error message appears:

        root@FileServer:~# jamvm
        ld.so does not support TLS, but program uses it!

        What a shame, I really wanted to run VideoLANs VLMa web interface: http://www.videolan.org/vlma/doc/setup.html

        Any suggestions?
        -J




        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/nslu2-linux/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/nslu2-linux/join
           (Yahoo! ID required)

        <*> To change settings via email:
           mailto:nslu2-linux-digest@yahoogroups.com
           mailto:nslu2-linux-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           nslu2-linux-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           http://docs.yahoo.com/info/terms/

         

         

         

         

         

      • rob.lougher
        ... The latest versions of JamVM will use thread-local-storage (TLS) if the compiler supports it, as it leads to a minor performance improvement. Your problem
        Message 3 of 19 , Apr 8, 2009
          --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@...> wrote:
          >
          > Sebastien,
          >
          >
          >
          > Thanks for the elaborate explanation. Once you have your USB issues sorted, it would be great if you could try jamvm on 5.3 then. The error message occurs even when I run jamvm without any parameters at all, meaning that I am not even asking it to run any Java byte code.
          >
          >
          >
          > I wonder what potential issues could result if I replace ld.so with a newer version. And where would I be able to obtain a newer version?
          >
          >

          The latest versions of JamVM will use thread-local-storage (TLS) if the compiler supports it, as it leads to a minor performance improvement. Your problem is you're installing prebuilt packages obviously built on a system that supports TLS, but your system doesn't...

          Really, you have two options :

          1) Upgrade your system (replacing ld.so on a running system is _very_ dangerous).

          2) Build JamVM yourself. Hopefully, this will not detect that your system supports TLS (but it can in some systems where the compiler supports it, but nothing else does). In this case you can manually disable TLS... Of course, this option requires the ability to build packages yourself. On embedded systems this is usually via cross-compilation, which means you need a toolchain...

          Hope this helps,

          Rob.

          >
          > Thanks
          >
          > Jan
          >
          >
          >
        • Jan
          Thanks Rob. I heard you loud and clear -- next stop (after my upcoming vacation) is SlugOS 5.3... :) ... From: nslu2-linux@yahoogroups.com
          Message 4 of 19 , Apr 8, 2009
            Thanks Rob. I heard you loud and clear -- next stop (after my upcoming
            vacation) is SlugOS 5.3... :)

            -----Original Message-----
            From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On
            Behalf Of rob.lougher
            Sent: Wednesday, April 08, 2009 4:50 PM
            To: nslu2-linux@yahoogroups.com
            Subject: [nslu2-linux] Re: jamvm (Java VM) on SlugOS ==> "ld.so does not
            support TLS, but program uses it"

            --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@...> wrote:
            >
            > Sebastien,
            >
            >
            >
            > Thanks for the elaborate explanation. Once you have your USB issues
            sorted, it would be great if you could try jamvm on 5.3 then. The error
            message occurs even when I run jamvm without any parameters at all, meaning
            that I am not even asking it to run any Java byte code.
            >
            >
            >
            > I wonder what potential issues could result if I replace ld.so with a
            newer version. And where would I be able to obtain a newer version?
            >
            >

            The latest versions of JamVM will use thread-local-storage (TLS) if the
            compiler supports it, as it leads to a minor performance improvement. Your
            problem is you're installing prebuilt packages obviously built on a system
            that supports TLS, but your system doesn't...

            Really, you have two options :

            1) Upgrade your system (replacing ld.so on a running system is _very_
            dangerous).

            2) Build JamVM yourself. Hopefully, this will not detect that your system
            supports TLS (but it can in some systems where the compiler supports it, but
            nothing else does). In this case you can manually disable TLS... Of
            course, this option requires the ability to build packages yourself. On
            embedded systems this is usually via cross-compilation, which means you need
            a toolchain...

            Hope this helps,

            Rob.

            >
            > Thanks
            >
            > Jan
            >
            >
            >




            ------------------------------------

            Yahoo! Groups Links
          • rob.lougher
            ... Yes, this is probably your best option as it should save compatibility problems in the future (not that I really know, as I don t have an NSLU2, I just
            Message 5 of 19 , Apr 8, 2009
              --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@...> wrote:
              >
              > Thanks Rob. I heard you loud and clear -- next stop (after my upcoming
              > vacation) is SlugOS 5.3... :)
              >

              Yes, this is probably your best option as it should save compatibility problems in the future (not that I really know, as I don't have an NSLU2, I just develop JamVM).

              I just hope after all this JamVM does what you want :)

              Rob.

              > -----Original Message-----
              > From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On
              > Behalf Of rob.lougher
              > Sent: Wednesday, April 08, 2009 4:50 PM
              > To: nslu2-linux@yahoogroups.com
              > Subject: [nslu2-linux] Re: jamvm (Java VM) on SlugOS ==> "ld.so does not
              > support TLS, but program uses it"
              >
              > --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@> wrote:
              > >
              > > Sebastien,
              > >
              > >
              > >
              > > Thanks for the elaborate explanation. Once you have your USB issues
              > sorted, it would be great if you could try jamvm on 5.3 then. The error
              > message occurs even when I run jamvm without any parameters at all, meaning
              > that I am not even asking it to run any Java byte code.
              > >
              > >
              > >
              > > I wonder what potential issues could result if I replace ld.so with a
              > newer version. And where would I be able to obtain a newer version?
              > >
              > >
              >
              > The latest versions of JamVM will use thread-local-storage (TLS) if the
              > compiler supports it, as it leads to a minor performance improvement. Your
              > problem is you're installing prebuilt packages obviously built on a system
              > that supports TLS, but your system doesn't...
              >
              > Really, you have two options :
              >
              > 1) Upgrade your system (replacing ld.so on a running system is _very_
              > dangerous).
              >
              > 2) Build JamVM yourself. Hopefully, this will not detect that your system
              > supports TLS (but it can in some systems where the compiler supports it, but
              > nothing else does). In this case you can manually disable TLS... Of
              > course, this option requires the ability to build packages yourself. On
              > embedded systems this is usually via cross-compilation, which means you need
              > a toolchain...
              >
              > Hope this helps,
              >
              > Rob.
              >
              > >
              > > Thanks
              > >
              > > Jan
              > >
              > >
              > >
              >
              >
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
            • Mike (mwester)
              ... Astonishing! :-) Hello world in Java --- in 32 MB of RAM! (Most every Java app I encounter in the commercial world measures required memory in
              Message 6 of 19 , Apr 8, 2009
                Jan wrote:
                > Thanks Rob. I heard you loud and clear -- next stop (after my upcoming
                > vacation) is SlugOS 5.3... :)

                Astonishing! :-) "Hello world" in Java --- in 32 MB of RAM! (Most
                every Java app I encounter in the commercial world measures required
                memory in multiple gigabytes.)

                [Can you tell I don't like Java much? :-) Sorry, couldn't resist the
                comments there, it truly is amazing that it works on such a small device.]

                I did try it, just to make sure all is well on 5.3-beta. It installs
                and works fine.

                Follow the SlugOS install guide on the wiki, and at least read it even
                if you are an experienced SlugOS user, and note that opkg installs stuff
                from the SlugOS feeds, and after you run the magic script, ipkg will be
                available to install stuff from the optware feeds (which is where the
                Java tools will be).

                - Mike "C and Perl forever!" (mwester)
              • Jan
                Very cool! I had no idea that you were the developer of JamVM and that you were in fact also part of this discussion group. Keep up the good work and I will
                Message 7 of 19 , Apr 8, 2009
                  Very cool! I had no idea that you were the developer of JamVM and that you
                  were in fact also part of this discussion group. Keep up the good work and I
                  will report back once I've rebuilt my slug. Won't be for another three
                  weeks, but I will eventually get to it.

                  Or perhaps I should just get a second slug to ease the transition pains :)

                  Jan

                  -----Original Message-----
                  From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On
                  Behalf Of rob.lougher
                  Sent: Wednesday, April 08, 2009 7:44 PM
                  To: nslu2-linux@yahoogroups.com
                  Subject: [nslu2-linux] Re: jamvm (Java VM) on SlugOS ==> "ld.so does not
                  support TLS, but program uses it"

                  --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@...> wrote:
                  >
                  > Thanks Rob. I heard you loud and clear -- next stop (after my upcoming
                  > vacation) is SlugOS 5.3... :)
                  >

                  Yes, this is probably your best option as it should save compatibility
                  problems in the future (not that I really know, as I don't have an NSLU2, I
                  just develop JamVM).

                  I just hope after all this JamVM does what you want :)

                  Rob.

                  > -----Original Message-----
                  > From: nslu2-linux@yahoogroups.com [mailto:nslu2-linux@yahoogroups.com] On
                  > Behalf Of rob.lougher
                  > Sent: Wednesday, April 08, 2009 4:50 PM
                  > To: nslu2-linux@yahoogroups.com
                  > Subject: [nslu2-linux] Re: jamvm (Java VM) on SlugOS ==> "ld.so does not
                  > support TLS, but program uses it"
                  >
                  > --- In nslu2-linux@yahoogroups.com, Jan <obiyawn@> wrote:
                  > >
                  > > Sebastien,
                  > >
                  > >
                  > >
                  > > Thanks for the elaborate explanation. Once you have your USB issues
                  > sorted, it would be great if you could try jamvm on 5.3 then. The error
                  > message occurs even when I run jamvm without any parameters at all,
                  meaning
                  > that I am not even asking it to run any Java byte code.
                  > >
                  > >
                  > >
                  > > I wonder what potential issues could result if I replace ld.so with a
                  > newer version. And where would I be able to obtain a newer version?
                  > >
                  > >
                  >
                  > The latest versions of JamVM will use thread-local-storage (TLS) if the
                  > compiler supports it, as it leads to a minor performance improvement. Your
                  > problem is you're installing prebuilt packages obviously built on a system
                  > that supports TLS, but your system doesn't...
                  >
                  > Really, you have two options :
                  >
                  > 1) Upgrade your system (replacing ld.so on a running system is _very_
                  > dangerous).
                  >
                  > 2) Build JamVM yourself. Hopefully, this will not detect that your system
                  > supports TLS (but it can in some systems where the compiler supports it,
                  but
                  > nothing else does). In this case you can manually disable TLS... Of
                  > course, this option requires the ability to build packages yourself. On
                  > embedded systems this is usually via cross-compilation, which means you
                  need
                  > a toolchain...
                  >
                  > Hope this helps,
                  >
                  > Rob.
                  >
                  > >
                  > > Thanks
                  > >
                  > > Jan
                • Brian Zhou
                  Hi Rob, Glad to have you here. I tested jamvm on a couple of optware platforms (arm, armeb, ppc, mipsel and x86) yesterday, turns out with the same
                  Message 8 of 19 , Apr 9, 2009
                    Hi Rob,

                    Glad to have you here.

                    I tested jamvm on a couple of optware platforms (arm, armeb, ppc, mipsel and x86) yesterday, turns out with the same make/jamvm.mk, 1.5.1 works but 1.5.2 does not. On all platforms 1.5.2 always errors out with "NoClassDefFoundError HelloWorld". From strace, it does not even try to read the class file.
                    So for now I reverted optware ipk's to 1.5.1.

                    The optware make/jamvm.mk can be viewed here:
                    http://trac.nslu2-linux.org/optware/browser/trunk/make/jamvm.mk

                    Do you have any suggestion what I should look and adjust?

                    Best regards,

                    -Brian

                    --- In nslu2-linux@yahoogroups.com, "rob.lougher" <rob.lougher@...> wrote:
                    >
                    > The latest versions of JamVM will use thread-local-storage (TLS) if the compiler supports it, as it leads to a minor performance improvement. Your problem is you're installing prebuilt packages obviously built on a system that supports TLS, but your system doesn't...
                    >
                    > Really, you have two options :
                    >
                    > 1) Upgrade your system (replacing ld.so on a running system is _very_ dangerous).
                    >
                    > 2) Build JamVM yourself. Hopefully, this will not detect that your system supports TLS (but it can in some systems where the compiler supports it, but nothing else does). In this case you can manually disable TLS... Of course, this option requires the ability to build packages yourself. On embedded systems this is usually via cross-compilation, which means you need a toolchain...
                    >
                    > Hope this helps,
                    >
                    > Rob.
                    >
                    > >
                    > > Thanks
                    > >
                    > > Jan
                    > >
                    > >
                    > >
                    >
                  • Brian Zhou
                    There re actually a few options for running java on nslu2, availability depends on firmware version. 1. jamvm (available on almost all firmware) 2. Sun
                    Message 9 of 19 , Apr 9, 2009
                      There're actually a few options for running java on nslu2, availability depends on firmware version.

                      1. jamvm (available on almost all firmware)
                      2. Sun phoneme-advanced cvm (java 1.2, but quite fast)
                      3. cacao (currently only available on armel EABI platforms)

                      I think OE also have jamvm and cacao build recipes, it's just not built for slugos.

                      I use java in my day job. I cannot say I like java that much. But it's certainly used a lot.

                      -Brian

                      --- In nslu2-linux@yahoogroups.com, "Mike (mwester)" <mwester@...> wrote:
                      >
                      > Astonishing! :-) "Hello world" in Java --- in 32 MB of RAM! (Most
                      > every Java app I encounter in the commercial world measures required
                      > memory in multiple gigabytes.)
                      >
                      > [Can you tell I don't like Java much? :-) Sorry, couldn't resist the
                      > comments there, it truly is amazing that it works on such a small device.]
                      >
                      > I did try it, just to make sure all is well on 5.3-beta. It installs
                      > and works fine.
                      >
                      > Follow the SlugOS install guide on the wiki, and at least read it even
                      > if you are an experienced SlugOS user, and note that opkg installs stuff
                      > from the SlugOS feeds, and after you run the magic script, ipkg will be
                      > available to install stuff from the optware feeds (which is where the
                      > Java tools will be).
                      >
                      > - Mike "C and Perl forever!" (mwester)
                      >
                    • rob.lougher
                      Hi Brian, ... Just so I understand, the only thing different is JamVM? Same version of GNU Classpath, gcc, etc., and 1.5.1 works but 1.5.2 doesn t? I ve
                      Message 10 of 19 , Apr 9, 2009
                        Hi Brian,

                        --- In nslu2-linux@yahoogroups.com, "Brian Zhou" <b88zhou@...> wrote:
                        >
                        > Hi Rob,
                        >
                        > Glad to have you here.
                        >
                        > I tested jamvm on a couple of optware platforms (arm, armeb, ppc, mipsel and x86) yesterday, turns out with the same make/jamvm.mk, 1.5.1 works but 1.5.2 does not. On all platforms 1.5.2 always errors out with "NoClassDefFoundError HelloWorld". From strace, it does not even try to read the class file.
                        > So for now I reverted optware ipk's to 1.5.1.
                        >
                        > The optware make/jamvm.mk can be viewed here:
                        > http://trac.nslu2-linux.org/optware/browser/trunk/make/jamvm.mk
                        >

                        Just so I understand, the only thing different is JamVM? Same version of GNU Classpath, gcc, etc., and 1.5.1 works but 1.5.2 doesn't?

                        I've looked at the problem Drew Gibson reported a few days ago (Trying to run .jar files from i386 on unslung). Here, the classpath ends up as null no matter what you set it to. It looks as if this is what you're seeing as well. To confirm, do:

                        jamvm foo

                        This should show an error, but importantly, the urls=[...] should have one entry for the current directory, e.g.:

                        Exception in thread "main" java.lang.NoClassDefFoundError: foo
                        <<No stacktrace available>>
                        Caused by: java.lang.ClassNotFoundException: foo not found in java.lang.ClassLoader$1{urls=[file:/home/rob/Desktop/bug/./], parent=null}
                        at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
                        at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
                        at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
                        at java.lang.ClassLoader.loadClass(ClassLoader.java:293)

                        But instead, it shows urls=[] (i.e. no classpath).

                        > Do you have any suggestion what I should look and adjust?
                        >

                        To be honest, I'm clueless right now, and before I couldn't see how to go forward (as I don't have an nslu2). But as you say it occurs on ppc and x86 optware platforms, I should be able to reproduce it here. Are there any instructions online as to how to setup an optware system (I'm guessing I can create one qemu/kvm)? I'll do some googling :)

                        Thanks,

                        Rob.

                        > Best regards,
                        >
                        > -Brian
                        >
                        > --- In nslu2-linux@yahoogroups.com, "rob.lougher" <rob.lougher@> wrote:
                        > >
                        > > The latest versions of JamVM will use thread-local-storage (TLS) if the compiler supports it, as it leads to a minor performance improvement. Your problem is you're installing prebuilt packages obviously built on a system that supports TLS, but your system doesn't...
                        > >
                        > > Really, you have two options :
                        > >
                        > > 1) Upgrade your system (replacing ld.so on a running system is _very_ dangerous).
                        > >
                        > > 2) Build JamVM yourself. Hopefully, this will not detect that your system supports TLS (but it can in some systems where the compiler supports it, but nothing else does). In this case you can manually disable TLS... Of course, this option requires the ability to build packages yourself. On embedded systems this is usually via cross-compilation, which means you need a toolchain...
                        > >
                        > > Hope this helps,
                        > >
                        > > Rob.
                        > >
                        > > >
                        > > > Thanks
                        > > >
                        > > > Jan
                        > > >
                        > > >
                        > > >
                        > >
                        >
                      • Brian Zhou
                        ... Yes. Everything else is the same, just 1.5.1 works but 1.5.2 does not. They re built with the same jamvm.mk except the version. ... I can confirm this is
                        Message 11 of 19 , Apr 9, 2009
                          --- In nslu2-linux@yahoogroups.com, "rob.lougher" <rob.lougher@...> wrote:
                          >
                          > Just so I understand, the only thing different is JamVM? Same version of GNU Classpath, gcc, etc., and 1.5.1 works but 1.5.2 doesn't?
                          >
                          Yes. Everything else is the same, just 1.5.1 works but 1.5.2 does not.
                          They're built with the same jamvm.mk except the version.

                          > I've looked at the problem Drew Gibson reported a few days ago (Trying to run .jar files from i386 on unslung). Here, the classpath ends up as null no matter what you set it to. It looks as if this is what you're seeing as well. To confirm, do:
                          >
                          > jamvm foo
                          >
                          > This should show an error, but importantly, the urls=[...] should have one entry for the current directory, e.g.:
                          >
                          > Exception in thread "main" java.lang.NoClassDefFoundError: foo
                          > <<No stacktrace available>>
                          > Caused by: java.lang.ClassNotFoundException: foo not found in java.lang.ClassLoader$1{urls=[file:/home/rob/Desktop/bug/./], parent=null}
                          > at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
                          > at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
                          > at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
                          > at java.lang.ClassLoader.loadClass(ClassLoader.java:293)
                          >
                          > But instead, it shows urls=[] (i.e. no classpath).
                          >

                          I can confirm this is the case.

                          # with jamvm 1.5.1
                          # jamvm foo
                          java.lang.NoClassDefFoundError: foo
                          <<No stacktrace available>>
                          Caused by: java.lang.ClassNotFoundException: foo not found in java.lang.ClassLoader$1{urls=[file:/home/bzhou/./], parent=null}
                          at java.net.URLClassLoader.findClass(URLClassLoader.java:529)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
                          at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:293)

                          # with jamvm 1.5.2
                          # jamvm foo
                          Exception in thread "main" java.lang.NoClassDefFoundError: foo
                          <<No stacktrace available>>
                          Caused by: java.lang.ClassNotFoundException: foo not found in java.lang.ClassLoader$1{urls=[], parent=null}
                          at java.net.URLClassLoader.findClass(URLClassLoader.java:529)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
                          at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
                          at java.lang.ClassLoader.loadClass(ClassLoader.java:293)

                          >
                          > To be honest, I'm clueless right now, and before I couldn't see how to go forward (as I don't have an nslu2). But as you say it occurs on ppc and x86 optware platforms, I should be able to reproduce it here. Are there any instructions online as to how to setup an optware system (I'm guessing I can create one qemu/kvm)? I'll do some googling :)
                          >

                          On an x86 linux box, you can try the optware/ts509 feed. Setup:

                          # wget http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable/ipkg-opt_0.99.163-10_i686.ipk
                          # tar -xOvzf ipkg-opt_*_i686.ipk ./data.tar.gz | tar -C / -xzvf -
                          # mkdir -p /opt/etc/ipkg
                          # echo "src ts509 http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable" > /opt/etc/ipkg/ts509-feed.conf
                          # /opt/bin/ipkg update
                          # /opt/bin/ipkg install classpath jamvm

                          Right now, jamvm 1.5.1 is in the feed.
                          I've uploaded jamvm_1.5.2-1_i686.ipk to nslu2-general yahoo groups Files, Misc Files.

                          You can also build the ipk's yourself, steps:

                          $ svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
                          $ cd optware
                          $ make ts509-target
                          $ cd ts509
                          $ make directories ipkg-utils toolchain
                          $ make jamvm-ipk
                          $ make jamvm-dirclean jamvm-ipk JAMVM_VERSION=1.5.2

                          Thanks a lot,

                          -Brian
                        • rob.lougher
                          ... Thanks for the instructions, with these I was able to build 1.5.2 and reproduce the problem. The reason is straight-forward. JamVM 1.5.2 requires GNU
                          Message 12 of 19 , Apr 10, 2009
                            --- In nslu2-linux@yahoogroups.com, "Brian Zhou" <b88zhou@...> wrote:
                            >
                            > On an x86 linux box, you can try the optware/ts509 feed. Setup:
                            >
                            > # wget http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable/ipkg-opt_0.99.163-10_i686.ipk
                            > # tar -xOvzf ipkg-opt_*_i686.ipk ./data.tar.gz | tar -C / -xzvf -
                            > # mkdir -p /opt/etc/ipkg
                            > # echo "src ts509 http://ipkg.nslu2-linux.org/feeds/optware/ts509/cross/unstable" > /opt/etc/ipkg/ts509-feed.conf
                            > # /opt/bin/ipkg update
                            > # /opt/bin/ipkg install classpath jamvm
                            >
                            > Right now, jamvm 1.5.1 is in the feed.
                            > I've uploaded jamvm_1.5.2-1_i686.ipk to nslu2-general yahoo groups Files, Misc Files.
                            >
                            > You can also build the ipk's yourself, steps:
                            >
                            > $ svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
                            > $ cd optware
                            > $ make ts509-target
                            > $ cd ts509
                            > $ make directories ipkg-utils toolchain
                            > $ make jamvm-ipk
                            > $ make jamvm-dirclean jamvm-ipk JAMVM_VERSION=1.5.2
                            >

                            Thanks for the instructions, with these I was able to build 1.5.2 and reproduce the problem.

                            The reason is straight-forward. JamVM 1.5.2 requires GNU Classpath 0.98, but the installed Classpath is 0.97.2. As GNU Classpath is Java, you can't check versions at configure time. Compatible versions are listed in the README, but this is less than ideal.

                            I tested building Classpath 0.98 and everything worked OK. However, you will need to modify the upstream site listed in classpath.mk from http://builder.classpath.org/dist to ftp://ftp.gnu.org/gnu/classpath, as 0.98 doesn't exist on builder (ftp.gnu.org is the official download location).

                            Thanks,
                            Rob.

                            > Thanks a lot,
                            >
                            > -Brian
                            >
                          • Brian Zhou
                            ... Thanks Rob, I ve upgraded classpath to 0.98 (requires downloading of antlr.jar at build time), and have jamvm depends on classpath ( =0.98). It will be in
                            Message 13 of 19 , Apr 10, 2009
                              > The reason is straight-forward. JamVM 1.5.2 requires GNU Classpath 0.98, but the installed Classpath is 0.97.2. As GNU Classpath is Java, you can't check versions at configure time. Compatible versions are listed in the README, but this is less than ideal.
                              >
                              > I tested building Classpath 0.98 and everything worked OK. However, you will need to modify the upstream site listed in classpath.mk from http://builder.classpath.org/dist to ftp://ftp.gnu.org/gnu/classpath, as 0.98 doesn't exist on builder (ftp.gnu.org is the official download location).
                              >

                              Thanks Rob, I've upgraded classpath to 0.98 (requires downloading of antlr.jar at build time), and have jamvm depends on classpath (>=0.98). It will be in all feeds in an hour or so.

                              Best regards,

                              -Brian
                            • Drew Gibson
                              ... Thanks Rob, That fixed my issue too and simplifies my phone setup considerably! regards, Drew
                              Message 14 of 19 , Apr 11, 2009
                                Brian Zhou wrote:
                                The reason is straight-forward.  JamVM 1.5.2 requires GNU Classpath 0.98, but the installed Classpath is 0.97.2.  As GNU Classpath is Java, you can't check versions at configure time.  Compatible versions are listed in the README, but this is less than ideal.
                                
                                I tested building Classpath 0.98 and everything worked OK.  However, you will need to modify the upstream site listed in classpath.mk from http://builder.classpath.org/dist to ftp://ftp.gnu.org/gnu/classpath, as 0.98 doesn't exist on builder (ftp.gnu.org is the official download location).
                                
                                    
                                Thanks Rob, I've upgraded classpath to 0.98 (requires downloading of antlr.jar at build time), and have jamvm depends on classpath (>=0.98). It will be in all feeds in an hour or so.
                                
                                Best regards,
                                
                                -Brian
                                  

                                Thanks Rob,

                                That fixed my issue too and simplifies my phone setup considerably!

                                regards,

                                Drew

                              Your message has been successfully submitted and would be delivered to recipients shortly.