Please see my responses below. On Wed, Jan 17, 2018 at 3:36 AM, Nadav Har'El <[email protected]> wrote:
> I'll commit this patch, but did you actually test this patch and the rest? > When I try > scripts/build image=apache-derby > scripts/run > > I get > Caused by: java.lang.UnsupportedClassVersionError: > org/apache/derby/drda/NetworkServerControl > : Unsupported major.minor version 52.0 > > This happens because this version of apache derby was compiled with Java 8 compiler (52 version) which means that you need at least Java 8 to run it as well as Java 7 does not understand Java 8 bytecode. > If I try > scripts/build image=openjdk8-fedora,apache-derby > > I get other strange errors perhaps related to access control. > > scripts/build image=openjdk8-zulu-full,apache-derby > I tend not to use the openjdk8-fedora because it seems to be flaky. I think it is mainly because this app is not pinned to a specific version and we always get newest and things keep changing. As I understand the fedora jdk package is not as self contained as the zulu one is in terms of dependant shared libraries. This is the error I am getting: Exception was caught while running -cp /db-derby/lib/derby.jar:/db-derby/lib/derbynet.jar:/db-derby/lib/derbytools.jar:/db-derby/lib/derbyclient.jar -Djava.security.policy=/db-derby/security.policy org.apache.derby.drda.NetworkServerControl start exception: io.osv.isolated.ContextFailedException: java.lang.InternalError io.osv.isolated.ContextFailedException: java.lang.InternalError at io.osv.isolated.Context.join(Context.java:63) at io.osv.isolated.IsolatedJvm.runSync(IsolatedJvm.java:159) at io.osv.isolated.MultiJarLoader$RunOnThread.run(MultiJarLoader.java:130) Caused by: java.lang.InternalError at sun.security.ec.SunEC.initialize(Native Method) at sun.security.ec.SunEC.access$000(SunEC.java:49) at sun.security.ec.SunEC$1.run(SunEC.java:61) at sun.security.ec.SunEC$1.run(SunEC.java:58) at java.security.AccessController.doPrivileged(Native Method) at sun.security.ec.SunEC.<clinit>(SunEC.java:58) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:221) at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206) at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187) at sun.security.jca.ProviderList.getProvider(ProviderList.java:233) at sun.security.jca.ProviderList.getIndex(ProviderList.java:263) at sun.security.jca.ProviderList.getProviderConfig(ProviderList.java:247) at sun.security.jca.ProviderList.getProvider(ProviderList.java:253) at java.security.Security.getProvider(Security.java:501) at org.apache.derby.impl.drda.DecryptionManager.<init>(Unknown Source) at org.apache.derby.impl.drda.NetworkServerControlImpl.<clinit>(Unknown Source) at org.apache.derby.drda.NetworkServerControl.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at io.osv.Jvm.runMain(Jvm.java:119) at io.osv.isolated.IsolatedJvm.access$400(IsolatedJvm.java:30) at io.osv.isolated.IsolatedJvm$3.run(IsolatedJvm.java:116) which is caused by Java failing to load libsunec.so ( https://github.com/frohoff/jdk8u-dev-jdk/blob/master/src/share/classes/sun/security/ec/SunEC.java#L60 ). It could be that some of the libraries libsunec.so is depending on are missing. Here is the list I get against fedora's libsunec.so: readelf -d apps/openjdk8-fedora/install/usr/lib/jvm/java/jre/lib/amd64/libsunec.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6] 0x0000000000000001 (NEEDED) Shared library: [libssl3.so] 0x0000000000000001 (NEEDED) Shared library: [libsmime3.so] 0x0000000000000001 (NEEDED) Shared library: [libnss3.so] 0x0000000000000001 (NEEDED) Shared library: [libnssutil3.so] 0x0000000000000001 (NEEDED) Shared library: [libplds4.so] 0x0000000000000001 (NEEDED) Shared library: [libplc4.so] 0x0000000000000001 (NEEDED) Shared library: [libnspr4.so] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] For comparison this is what I get against zulu's libsunec.so (this version is much bigger than fedora's one): readelf -d apps/openjdk8-zulu-full/install/usr/lib/jvm/java/jre/lib/amd64/libsunec.so | grep NEEDED 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] Out of curiosity does it mean that zulu's libsunec.so has statically linked in libpthread.so.0 but then I was under impression that OSv provides its own version of pthread API. How does it then work? Isn't there a conflict or somehow the elf loading logic in OSv makes sure that symbols from OSv pthread implementation supersede other pthread lib if part of the app? I hope my questions make sense. By the way I also had to manually fix the fedora package as I was getting this kind of errors with rpm2cpio: ln -sf java install/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.151-2.b12.fc28.x86_64 rm -rf install/usr/lib/jvm/java/jre/lib/security/cacerts rm -rf install/usr/lib/jvm/java/jre/lib/audio/* rpm2cpio upstream/tzdata-java-2017c-1.fc28.noarch.rpm | (cd install && cpio -id) 847 blocks rpm2cpio upstream/nspr-4.17.0-1.fc28.x86_64.rpm | (cd install && cpio -id) cpio: Can't write over symlinks: ./usr/lib64/libnspr4.so > Finally seems to work. > So I think the "wget -c" is the least of our worries regarding this > package... > If it depends on the openjdk8-zulu-full we can replace its dependency on a > generic "java" with a dependency on that specific version. But I don't know > why it does - > > Waldek, do you have any idea why openjdk8-zulu-full worked here and > openjdk8-fedora did not? > Also I think we may need the Java 8 packages to also provide a "java8" > feature, so applications can start specifying they need Java 8 (and Java 7 > is not good enough). > > > Good idea. It should be easy to do it using 'provides' and 'require'. I will prepare a patch. > > > -- > Nadav Har'El > [email protected] > > On Tue, Jan 16, 2018 at 9:42 PM, geraldo netto <[email protected]> > wrote: > >> Signed-off-by: geraldo netto <[email protected]> >> --- >> apache-derby/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/apache-derby/Makefile b/apache-derby/Makefile >> index 11d8c81..4c05e1a 100644 >> --- a/apache-derby/Makefile >> +++ b/apache-derby/Makefile >> @@ -5,7 +5,7 @@ VERSION := 10.14.1.0 >> module: ROOTFS >> >> db-derby-$(VERSION)-bin.tar.gz: >> - wget http://archive.apache.org/dist/db/derby/db-derby-$(VERSION)/ >> db-derby-$(VERSION)-bin.tar.gz >> + wget -c http://archive.apache.org/dist >> /db/derby/db-derby-$(VERSION)/db-derby-$(VERSION)-bin.tar.gz >> >> ROOTFS/db-derby: db-derby-$(VERSION)-bin.tar.gz >> mkdir -p ROOTFS/db-derby >> -- >> 2.7.4 >> >> -- >> 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. >> > > -- 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.
