On Wed, Jan 17, 2018 at 11:17 PM, Waldek Kozaczuk <[email protected]> wrote:
> > On Wed, Jan 17, 2018 at 3:36 AM, Nadav Har'El <[email protected]> wrote: > > 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. > Sorry, I forgot, this is a known bug: https://github.com/cloudius-systems/osv/issues/880 According to what I see we discovered in this bug (many months ago...) libsunec.so is not missing, but something is wrong with it. I don't know what :-( I haven't looked at this issue for many months. > It could be that some of the libraries libsunec.so is depending on are > missing. > We can verify this by running with -V and looking for shared libraries which weren't found. If I remember correctly this wasn't the problem in issue 880. > > 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. > Right. It shouldn't be statically linked with libpthread.so. That would be really silly, it would mean that one shared library (libsunec.so) will just include all the content of another library, for no good reason. Since libsunec.so is a shared library, not a stand-alone executable, there's no law saying it must "need" every shared library it really needs. It may just assume that the main program loaded this library earlier. It probably shouldn't, but it can. I'm guessing this is why this list may not be full. > 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. > Actually, if the application redefines an OSv function, that takes precedence over OSv's definition. So applications should not redefine libc functions. If they do, they would also have problems on Linux, because there too the application's functions will take preference to that of the shared library. > > 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. > We'll also need to have one default package named "java8" otherwise the user will still have to manually specify one of the packages which provide java8. >> >> -- >> 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.
