java failing w/weird not msg

[eyberg]

this is more than likely a product of my env but whatever it is we should fail a little bit more gracefully

➜  jt nvm run -a "HelloWorld" -c config.json -p 8080 /home/eyberg/jt/java                                                                                     
(children:(not:(contents:(host:not))usr:(children:(lib:(children:(libc.so.6:(contents:(host:/usr/lib/libc.so.6))))))lib64:(children:(ld-linux-x86-64.so.2:(contents:(host:/lib64/ld-linux-x86-64.so.2))))jt:(children:(java:(contents:(host:/home/eyberg/jt/java))))kernel:(contents:(host:.staging/stage3)))
program:/jt/java
arguments:[java HelloWorld]
environment:())
2018/10/11 12:26:56 couldn't open file not

panic: exit status 255

goroutine 1 [running]:
main.panicOnError(...)
        /home/eyberg/go/src/github.com/nanovms/nvm/nvm.go:57
main.buildImages(0x7ffe86e693b1, 0x14, 0x0, 0xc0000a6480)
        /home/eyberg/go/src/github.com/nanovms/nvm/nvm.go:114 +0x186
main.runCommandHandler(0xc0000f6780, 0xc00012e230, 0x1, 0x7)
        /home/eyberg/go/src/github.com/nanovms/nvm/nvm.go:96 +0x345
github.com/spf13/cobra.(*Command).execute(0xc0000f6780, 0xc00012e1c0, 0x7, 0x7, 0xc0000f6780, 0xc00012e1c0)
        /home/eyberg/go/src/github.com/spf13/cobra/command.go:766 +0x2cc
github.com/spf13/cobra.(*Command).ExecuteC(0xc0000f6f00, 0x4, 0x0, 0xc0000f6c80)                                                                              
        /home/eyberg/go/src/github.com/spf13/cobra/command.go:852 +0x2fd                                                                                      
github.com/spf13/cobra.(*Command).Execute(0xc0000f6f00, 0xc0000dbf48, 0x1)
        /home/eyberg/go/src/github.com/spf13/cobra/command.go:800 +0x2b                                                                                       
main.main()                                                                                                                                                   
        /home/eyberg/go/src/github.com/nanovms/nvm/nvm.go:206 +0x668

[eyberg]

it's cause of libjil ->

        linux-vdso.so.1 =>  (0x00007ffe3a3b8000)
        libjli.so => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fccf2fb2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fccf337c000)

eyberg@dungeon:~/jtest$ nvm run -p 8081 -c config.json /home/eyberg/jtest/java
yo3
(children:(not:(contents:(host:not))lib:(children:(x86_64-linux-gnu:(children:(libc.so.6:(contents:(host:/lib/x86_64-linux-gnu/libc.so.6))))))lib64:(children:(ld-linux-x86-64.so.2:(contents:(host:/lib64/l
d-linux-x86-64.so.2))))HelloWorld.class:(contents:(host:HelloWorld.class))home:(children:(eyberg:(children:(jtest:(children:(java:(contents:(host:/home/eyberg/jtest/java))))))))kernel:(contents:(host:.sta
ging/stage3.img)))
program:/home/eyberg/jtest/java
arguments:[java HelloWorld]
environment:())
exit status 255
nah here
2018/11/24 09:29:09 couldn't open file not

so it appears that it's just a packaging/symlink issue -

I found the jre pkg here ->

eyberg@dungeon:~/jtest$ locate libjli.so
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jli/libjli.so

eyberg@dungeon:~/jtest$ ldd java
        linux-vdso.so.1 =>  (0x00007ffd727f5000)
        libjli.so => not found
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f086d55d000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f086d927000)
eyberg@dungeon:~/jtest$ cp /usr/lib/jvm/java-8-openjdk-amd64/bin/java .
eyberg@dungeon:~/jtest$ ldd /usr/lib/jvm/java-8-openjdk-amd64/bin/java
        linux-vdso.so.1 =>  (0x00007ffc4a99c000)
        libjli.so => /usr/lib/jvm/java-8-openjdk-amd64/bin/../lib/amd64/jli/libjli.so (0x00007f56c66c3000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56c62f9000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56c60df000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56c5edb000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56c5cbe000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f56c68d2000)

of course that path goes away once you copy it over - maybe we should have a tool to copy libs and force the path before creating the manifest for cases like this?

[eyberg]

we should just try and make a manual pkg of this for now and see if that gets us to hello world an then we can come back later and make it a bit more proper

[mkhon]

bin/java has DT_RPATH/DT_RUNPATH set to "$ORIGIN/../lib" and libjli.so resides in "../lib" (relative to "java" executable).

With #714 and #715 libjli.so can be found successfully. I don't think we need a separate issue for this loading issue (all can be tracked in a parent issue #449).