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