Yes, now it works. I read your other messages about how it is frustrating to access the documentation on OSV and I confirm. In general is not easy to understand how to do things and what are the differences with various version of the software.
I thank you for your amazing help roberto Il giorno domenica 24 marzo 2019 14:59:57 UTC+1, Waldek Kozaczuk ha scritto: > > Try to replace osv-loader.qemu under ~/.capstan with newer version of > kernel - > https://github.com/cloudius-systems/osv/releases/download/v0.53.0/osv-loader.qemu > . > > On Sunday, March 24, 2019 at 2:47:36 AM UTC-4, robertob wrote: >> >> Thank you so much. >> >> I did all you wrote but I get these lines: >> >> OSv v0.24-472-gf240a59 >> eth0: 192.168.122.15 >> /java.so: failed looking up symbol _ZTINSt6thread6_StateE (typeinfo for >> std::thr >> >> >> [backtrace] >> 0x00000000003477cd <elf::object::symbol(unsigned int)+205> >> 0x0000000000399922 <elf::object::arch_relocate_rela(unsigned int, >> unsigned int, >> 0x00000000003446b3 <elf::object::relocate_rela()+147> >> 0x0000000000346247 <elf::object::relocate()+199> >> 0x0000000000349cdc <elf::program::load_object(std::string, std::vector< >> std::str> >> 0x000000000034a54b <elf::program::get_library(std::string, std::vector< >> std::strd >> 0x000000000041ccea <osv::application::application(std::string const&, std >> ::vect> >> 0x000000000041d515 <osv::application::run(std::string const&, std::vector >> <std::a >> 0x000000000041d73b <osv::application::run(std::vector<std::string, std:: >> allocato >> 0x0000000000213125 <do_main_thread(void*)+1717> >> 0x000000000044d6a5 <???+4511397> >> 0x00000000003f5477 <thread_main_c+39> >> 0x00000000003959a5 <???+3758501> >> 0x03209500032091ff <???+52466175> >> 0x00000000003f4b6f <???+4148079> >> 0xfb89485354415540 <???+1413567808> >> >> >> >> I cannot understand why the OSV version is 0.24. I think this is the >> probem now. >> >> regards >> r >> >> Il giorno venerdì 22 marzo 2019 21:45:38 UTC+1, Waldek Kozaczuk ha >> scritto: >> >>> So I have tested it myself and it looks like capstan (or OSv cannot >>> parse properly command line built by capstan) cannot properly handle >>> arguments when passes through YAML args list. >>> >>> It looks like you are using the "java" runtime that capstan advertises >>> which aims to make it easier to deploy and run Java apps on OSv by >>> automating process of constructing proper java command line and pull extra >>> packages. But apparently it has bugs and in general it comes with another >>> layer of abstraction which sometimes may make it more difficult to >>> troubleshoot the problem. >>> >>> You can always bypass this layer and use "native" runtime where you have >>> full control of how your OSv command like looks. This is BTW how I use >>> capstan. >>> >>> Here is how your meta/run.yaml would look like: >>> runtime: native >>> config_set: >>> *myconfig1*: >>> bootcmd: "/java.so -jar /Uni.jar -lsim -nTc 10 -sp 50000 -kp >>> ./keystore -tf ./config/topology.prop.xml -tIp 127.0.0.1 -d 60 -td >>> ./traces/ -cfg ./config/config.prop.xml" >>> config_set_default: *myconfig1* >>> >>> Also you need to change meta/package.yaml. See this example: >>> name: java-example >>> title: Java Example >>> author: Anonymous >>> version: "1.0" >>> require: >>> #- openjdk8-zulu-full >>> - openjdk8-zulu-compact3-with-java-beans >>> - osv.run-java >>> created: "2018-06-13T18:09:24-04:00" >>> >>> Please see you can use either full and slimmer version of Open JDK 8 >>> JRE. Also please note extra package which needs to be the last one and you >>> can download it from github >>> https://github.com/cloudius-systems/osv/releases/download/v0.51.0/osv.run-java.mpm/yaml >>> >>> and put it under $HOME/.capstan/packages/. Unfortunately the old >>> Mikelangelo S3 repo has pretty old (2018) artifacts and I am not sure if >>> anybody maintains it. You can always easily create your own S3 OSv packages >>> repo if you want. >>> >>> I have tested it with my hello world class and Java app received >>> arguments correctly: >>> Sv v0.53.0 >>> eth0: 192.168.122.15 >>> java.so: Starting JVM app using: io/osv/nonisolated/RunNonIsolatedJvmApp >>> java.so: Setting Java system classloader to >>> NonIsolatingOsvSystemClassLoader >>> Hello from Java on OSv! >>> Arg: -lsim >>> Arg: -nTc >>> Arg: 10 >>> Arg: -sp >>> Arg: 50000 >>> Arg: -kp >>> Arg: ./keystore >>> Arg: -tf >>> Arg: ./config/topology.prop.xml >>> Arg: -tIp >>> Arg: 127.0.0.1 >>> Arg: -d >>> Arg: 60 >>> Arg: -td >>> Arg: ./traces/ >>> Arg: -cfg >>> Arg: ./config/config.prop.xml >>> >>> I hope this helps, >>> Waldek >>> >>> On Wednesday, March 20, 2019 at 2:36:56 AM UTC-4, robertob wrote: >>>> >>>> Dear all, >>>> >>>> I have a "run.yaml" to run a JAR file. We need to pass a lot of >>>> arguments but something go wrong. This is the snippet of the run.yaml: >>>> >>>> *myconfig1:* >>>> * main: /Uni.jar* >>>> * args:* >>>> * - -lsim -nTc 10* >>>> * - -sp 50000* >>>> * - -kp ./keystore* >>>> * - -tf ./config/topology.prop.xml* >>>> * - -tIp 127.0.0.1* >>>> * - -d 60* >>>> * - -td ./traces/* >>>> * - -cfg ./config/config.prop.xml* >>>> >>>> When I run the image the message I got is the following: >>>> >>>> *"unrecognised option '-nTc'"* >>>> >>>> It seems to consider only the first argument and not the others. >>>> >>>> Any advice? >>>> >>>> Regards >>>> >>>> R >>>> >>> -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
