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
  • Jan Stanger
    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
    Message 1 of 19 , Apr 8, 2009
    • 0 Attachment

      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/

       

    • Sébastien Lorquet
      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
      Message 2 of 19 , Apr 8, 2009
      • 0 Attachment
        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
        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
        Message 3 of 19 , Apr 8, 2009
        • 0 Attachment

          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/

           

           

           

        • 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 4 of 19 , Apr 8, 2009
          • 0 Attachment
            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 5 of 19 , Apr 8, 2009
            • 0 Attachment

              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 6 of 19 , Apr 8, 2009
              • 0 Attachment
                --- 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 7 of 19 , Apr 8, 2009
                • 0 Attachment
                  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 8 of 19 , Apr 8, 2009
                  • 0 Attachment
                    --- 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 9 of 19 , Apr 8, 2009
                    • 0 Attachment
                      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 10 of 19 , Apr 8, 2009
                      • 0 Attachment
                        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 11 of 19 , Apr 9, 2009
                        • 0 Attachment
                          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 12 of 19 , Apr 9, 2009
                          • 0 Attachment
                            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 13 of 19 , Apr 9, 2009
                            • 0 Attachment
                              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 14 of 19 , Apr 9, 2009
                              • 0 Attachment
                                --- 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 15 of 19 , Apr 10, 2009
                                • 0 Attachment
                                  --- 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 16 of 19 , Apr 10, 2009
                                  • 0 Attachment
                                    > 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 17 of 19 , Apr 11, 2009
                                    • 0 Attachment
                                      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.