On Fri, Nov 3, 2023 at 6:45 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Den fre 3 nov. 2023 kl 10:00 skrev Stefan Sperling <s...@apache.org>: >> >> On Fri, Nov 03, 2023 at 12:00:32AM -0400, Nathan Hartman wrote: > > [...] >> >> > >> > >> > Hi all, >> > >> > Previously I mentioned I plan to RM for the upcoming 1.14.3 release. >> > This being my first time, I need to solve some issues first. >> > >> > One of these, which has been a stumbling block for me since the >> > beginning, is getting the JavaHL bindings to build and test >> > successfully. >> > >> > I have made progress on this, but not a complete breakthrough yet. >> > >> > The progress was discovering that I need to have $JAVA_HOME set in my >> > environment; without this, our build system (in build/ac-macros/java.m4) >> > fails to find javac and assigns 'none' to JAVAC; then, much later, >> > 'make check-javahl' tries to call this 'none', which unsurprisingly >> > doesn't work. (I was surprised that the other logic in this AC_DEFUN >> > couldn't find javac without $JAVA_HOME being set, but that's a subject >> > for another thread.) The clue was the use of $JAVA_HOME there. >> > >> > I tried various values for $JAVA_HOME but nothing that seemed sensible >> > worked; based on a StackOverflow answer [1], I ended up setting >> > $JAVA_HOME as follows: >> > >> > $ export JAVA_HOME=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::") >> > >> > On my system, this sets $JAVA_HOME to: >> > /usr/lib/jvm/java-17-openjdk-amd64 > > > In my case (Ubuntu 23.04), I need to use the --with-jdk argument to configure: > [[[ > $ ./configure --enable-javahl --with-jdk=/usr/lib/jvm/java-17-openjdk-amd64/ > ]]] > otherwise I get the following error message: > [[[ > configure: error: Cannot compile JavaHL without a suitable JDK. > Please specify a suitable JDK using the --with-jdk option. > ]]] > Don't know if&why the build on MacOS is different. > >> >> > >> > This value seems a little strange IMHO but it finally got 'configure' to >> > find the JDK successfully and got me past the longstanding 'none' >> > problem! > > > Great! There are some MacOS specific instructions in the building > instructions for JavaHL [2]. Don't know if this refers to your problem or not, > >> >> > >> > But then I promptly ran into the next issue: >> > >> > [[[ >> > >> > $ make check-javahl >> > (snip) >> > /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xcheck:jni >> > "-Dtest.rootdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/test-work" >> > "-Dtest.srcdir=/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl" >> > "-Dtest.rooturl=" "-Dtest.fstype=" >> > "-Djava.library.path=:/home/nathan/ramdrive/svndev/prefix/svn-1.14.x/lib" >> > -classpath >> > "subversion/bindings/javahl/classes:/home/nathan/ramdrive/svndev/svn-1.14.x/subversion/bindings/javahl/src:" >> > "-Dtest.cleanup=" "-Dtest.tests=" >> > org.apache.subversion.javahl.RunTests >> > Error: Could not find or load main class >> > org.apache.subversion.javahl.RunTests >> > Caused by: java.lang.ClassNotFoundException: >> > org.apache.subversion.javahl.RunTests >> > make: *** [Makefile:530: check-apache-javahl] Error 1 >> > >> > ]]] >> > >> > If I understand correctly, there should be a file called >> > 'RunTests.class' in one of the directories specified with -classpath >> > above. Well, there are other .class files to be found there, but not >> > RunTests.class. A search for RunTests with any (or no) extension in the >> > 1.14.x tree gives these two RunTests.java (not .class) files: >> > >> > $ find . -name RunTests\* >> > ./subversion/bindings/javahl/tests/org/apache/subversion/javahl/RunTests.java >> > ./subversion/bindings/javahl/tests/org/tigris/subversion/javahl/RunTests.java >> > >> > Forgive me if this is something obvious, but I know almost nothing about >> > the Java ecosystem. :-) > > > A .class is basically a .o file but for the JVM. So I guess RunTests.java was > never compiled. > >> >> > >> > I'll have to continue this exploration tomorrow, but I'm at least glad >> > to finally have made progress on a longstanding stumbling block. >> > >> > Meanwhile, any clues would be appreciated! >> > >> > [1] https://stackoverflow.com/a/29622512 >> > >> > Cheers, >> > Nathan >> > >> >> In my build script (in Subversion's tree at tools/dev/unix-build/) I pass the >> following flags to Subversion's configure script if JavaHL is enabled: >> >> --enable-javahl=yes --with-jdk --with-jikes=no \ >> --with-junit=$(DISTDIR)/$(JUNIT_DIST) >> >> Did you also pass --with-junit? > > > I did some tests and it seems that the --with-junit=/path/to/junit-X.Y.jar is > causing RunTests.java to be built, I can reproduce Nathan's error if I don't > add this option to configure. > >> >> >> For some reason I don't recall, my build script is fetching a self-hosted >> junit JAR file from here: https://stsp.name/distfiles/junit-4.10.jar >> (sha256: 36a747ca1e0b86f6ea88055b8723bb87030d627766da6288bf077afdeeb0f75a) > > > The build instructions for javahl [2] say that you should download JUnit from > https://junit.org/ ("4.11 has been tested"). I assume you've optimised away > the step of going to the website to download the jar (I'm doing something > similar for my own builds).. > > >> Given that you have self-compiled svn libraries in a non-standard prefix >> you might also want to try setting LD_LIBRARY_PATH when invoking the tests. >> Loading a wrong set of libsvn_*.so files would certainly cause issues, and >> the >> ld.so runtime linker probably won't see JVM settings like >> -Djava.library.path. >> >> env LD_LIBRARY_PATH="/home/nathan/ramdrive/svndev/prefix/svn-1.14.x/lib" \ >> make check-all-javahl >>
The scripts I used are here: https://github.com/markphip/svnrm/tree/main/scripts I built on a clean Debian install and the scripts get all the packages needed before running configure etc. My recollection of the main complication going forward was what to do about Python. I needed to use an older Debian base so we could still build for Python 2.x Mark
