https://bugzilla.redhat.com/show_bug.cgi?id=1971512 --- Comment #14 from jiri vanek <jvanek@xxxxxxxxxx> --- (In reply to Severin Gehwolf from comment #7) > (In reply to jiri vanek from comment #4) > > > - JNI shared objects MUST be placed in %{_libdir}/%{name}. See: > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#JNI > > > > quoting: > > "Java programs that wish to make calls into native libraries do so via the > > Java Native Interface (JNI). A Java package uses JNI if it contains a .so > > file. Note that this file can be embedded within JAR files themselves." > > !Note that this file can be embedded within JAR files themselves.! > > This is from the "Applicability" section of the guidelines. I.e. how do I > know whether or not a jar uses JNI. I'm working on a patch to not embed the > JNI .so file and will keep you posted. Ok. If you inisits, will be done. (In reply to Severin Gehwolf from comment #8) > (In reply to jiri vanek from comment #4) > > > - Why the criu-devel *runtime* dependency? > > > > Right. It is indeed runtime dependence(thats why it is so highlighted), as > > according to Christine, it is not only header file, but the connector to the > > criu. I was not investigating more on this topic. > > Well, it may be a *build* dependency, but my suspicion on why a runtime dep > on criu-devel is needed is likely for the unversioned libcriu.so link so > that System.loadLibrary("criu") works. If that's the case, it's not a good > reason. We should be able to work around this limitation by using the > versioned .so instead and depend only on criu-libs. I am looking into that > too. Thanx a lot. (In reply to Severin Gehwolf from comment #9) > (In reply to jiri vanek from comment #6) > > > > [!]: Package should compile and build into binary rpms on all supported > > > > architectures. > > > > Please provide a link to a scratch build > > > > > > Sure! https://koji.fedoraproject.org/koji/taskinfo?taskID=71043006 > > > > > > The failure on aarch64 is unexpected! > > Two observations: > > 1.) It looks like java.library.path is wrong on aarch64 JDK 11 builds. It > should > include /usr/lib64 instead of /usr/lib. That's an OpenJDK bug. See bug > 1977671. Thanx! > 2.) criu is not available for i686 so this package will have the same > limitation. > I.e. exclude arch i686 Yup. I was aware. Thus mentioned only aarch64 as unexpected. (In reply to Severin Gehwolf from comment #10) > (In reply to Severin Gehwolf from comment #9) > > 1.) It looks like java.library.path is wrong on aarch64 JDK 11 builds. It should > > include /usr/lib64 instead of /usr/lib. That's an OpenJDK bug. See bug 1977671. > > The work-around for this is to set LD_LIBRARY_PATH=/usr/lib64 prior to > running the maven build on aarch64. Users will have to do the same when > running jigawatts on aarch64 until the OpenJDK bug is fixed. Will be done. (In reply to Severin Gehwolf from comment #11) > Here is an SRPM which does proper installing of the .so JNI into %{_libdir}, > produces proper debuginfo packages and doesn't *runtime* require criu-devel. > > https://jerboaa.fedorapeople.org/rpm/jigawatts-0-0.0.pre.1. > c15dd4c19e81cbcefe419a99ebaa3af7c5c60c5e.fc34.src.rpm > > <mock-chroot> sh-5.1# rpm -ql jigawatts > /usr/lib/.build-id > /usr/lib/.build-id/1b > /usr/lib/.build-id/1b/10e64b7db2bbab054561633027911a0d27dd2e > /usr/lib/java/jigawatts > /usr/lib/java/jigawatts/jigawatt.jar > /usr/lib64/libJigawatts.so > /usr/share/doc/jigawatts > /usr/share/doc/jigawatts/README.md > /usr/share/licenses/jigawatts > /usr/share/licenses/jigawatts/LICENSE.md > /usr/share/maven-metadata/jigawatts.xml > /usr/share/maven-poms/jigawatts > /usr/share/maven-poms/jigawatts/jigawatt.pom > > The aarch64 problem is not fixed, yet, though. > > This works for me for a basic checkpoint/restore test. Ok. THat is some proactive review. Thanx a lot! Will discuse posibilities of usptreaming this change. (In reply to Severin Gehwolf from comment #12) > Please continue with this. Thanks! sure! (In reply to Severin Gehwolf from comment #13) > (In reply to Severin Gehwolf from comment #11) > > The aarch64 problem is not fixed, yet, though. > > The latest version of the SRPM here: > https://jerboaa.fedorapeople.org/rpm/jigawatts-0-0.0.pre.1. > c15dd4c19e81cbcefe419a99ebaa3af7c5c60c5e.fc34.src.rpm > > ... works around the aarch64 build failure. > > https://koji.fedoraproject.org/koji/taskinfo?taskID=71125678 > > with: > > > # Work-around for RHBZ#1977671, /usr/lib64 missing on default > java.library.path on aarch64 > %ifarch %{aarch64} > %pom_xpath_inject > "pom:build/pom:plugins/pom:plugin[pom:artifactId='maven-surefire-plugin']/ > pom:configuration" '<forkCount>1</forkCount> > <environmentVariables> > > <LD_LIBRARY_PATH>/usr/lib64:${project.build.directory}</LD_LIBRARY_PATH> > </environmentVariables>' > %else > %pom_xpath_inject > "pom:build/pom:plugins/pom:plugin[pom:artifactId='maven-surefire-plugin']/ > pom:configuration" '<forkCount>1</forkCount> > <environmentVariables> > <LD_LIBRARY_PATH>${project.build.directory}</LD_LIBRARY_PATH> > </environmentVariables>' > %endif Thanx a lot :) it is unexpected help. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
