On Fri, Nov 10, 2023 at 9:16 AM Daniel Sahlberg
<daniel.l.sahlb...@gmail.com> wrote:
>
> Den fre 10 nov. 2023 kl 15:09 skrev Nathan Hartman <hartman.nat...@gmail.com>:
>>
>> On Fri, Nov 10, 2023 at 8:02 AM Johan Corveleyn <jcor...@gmail.com> wrote:
>>>
>>> Hi Nathan,
>>>
>>> Sorry I haven't helped so far ... I should be able to say something
>>> useful here, since I'm a java dev in my dayjob. But I have been
>>> drowning a bit in that same dayjob lately, so I can barely find the
>>> time to scan these mails, and then forget about them because my
>>> attention is needed elsewhere.
>>>
>>> Anyway, I'll try to find some more time to take a closer look at the
>>> errors you get.
>>>
>>> Just as a first shot: if there is no RunTests.class in the location
>>> where it should be (one of the directories in the classpath), then it
>>> probably has not been compiled (or it has not been put in the right
>>> location). My first guess would also be, like Daniel mentioned, that
>>> you'll need the --with-junit option (referring to a junit-X.Y.jar
>>> somewhere on your system) and then the build scripts should compile
>>> the test classes.
>>>
>>> But I guess you already tried that, after Daniel's reply, and you're
>>> still running into problems. I'll take a closer look when you send
>>> your detailed mail then.
>>>
>>> --
>>> Johan
>>
>>
>>
>> Thanks Johan. Apologies for not sending the detailed mail yet. I wanted to
>> test a few specific theories but didn't get that far last night because I
>> hit a problem unrelated to SVN.
>>
>> One thing I'm struggling with is to understand which part of the build
>> system is supposed to compile RunTests, i.e., how/where the Java compiler is
>> being invoked on it. I'm not seeing it in the build logs, though I do see
>> the other Java files being compiled, so that's certainly interesting.
>
>
> I'm fairly sure that RunTests is compiled only when --with-junit is present
> (don't know if "present" is enough or if it has to point to a valid JAR
> file). Next question is if check-javahl should be available at all if
> --with-junit is missing or if check-javahl should make sure RunTests is
> built. Either way, I think it is a bug in the build system. This question
> should probably be carved out to its own e-mail thread. I'll try to figure
> something out and start a new thread.
>
> Kind regards,
> Daniel
Hi all,
Success! I have finally seen the JavaHL tests build and run!
I'd like to say a great big Thank You to everyone for helping me get
this far!
I was writing on IRC as I went through a number of steps [1].
What changed?
(1) Switched from my customized Makefile.svn to SVN's Makefile.svn, as
of the latest rev on trunk now (r1913724).
(2) Worked around a problem building gettext.
(3) Worked around a problem with serf-1.3.10 that DSahlberg saw also.
Regarding #1:
Note: Makefile.svn refers to tools/dev/unix-build/Makefile.svn.
My customized Makefile.svn was based on SVN's Makefile.svn@1871775. As
to my customizations, I can provide them later, but the tl;dr is:
(a) Build newer versions of some dependencies.
(b) Remove support for things I didn't need (like serf-old).
(c) Tweak some details to workaround build problems.
In all cases, any changes I made were done to workaround various build
problems I had encountered. Where appropriate, I upstreamed certain
changes: r1875794, r1872380. I didn't upstream changes that I
considered to be tweaks that only pertained to my machine.
This made it possible for me to build, develop, and test
[local,svn,serf] x [bdb,fsfs], plus all the bindings, except JavaHL
(until now).
In the meantime (since 2019 when r1871775 happened), SVN's Makefile.svn
has received many updates, including much improved handling of
Python-2/3 issues, so I wanted to adopt this and eliminate my
customized one.
Regarding #2:
Starting a few days ago, I ran into a weird problem with gettext. This
manifests with both versions of Makefile.svn (mine and SVN's).
I am not sure why this started happening, but when gettext's configure
runs, there is a nested gettext-tools's configure, which runs until it
prints "checking for Java virtual machine... yes" and then it gets
stuck there indefinitely. It happens with multiple versions of gettext
and after a few nights of investigation, I still don't know why. I
could find nothing about this online. (This is the "brick wall" I ran
into that I mentioned on IRC [2], for those who saw that and wondered.)
It is clearly some idiosyncracy of my machine.
Tonight I found a workaround:
I ran Makefile.svn's gettext-configure target, let it reach that point,
and then killed the process group.
Then I looked in the logs to see exactly how gettext's configure was
invoked.
I then invoked it "manually" by copying and pasting that incantation
into the terminal.
To my surprise, this ran to completion.
After this, I ran 'touch objdir/gettext/.configured' (this empty
dotfile serves as a flag for Makefile.svn not to run configure again).
Then I ran Makefile.svn's gettext-compile target, and it built
successfully.
Why it behaves differently when called from make vs when I call it
manually is still a mystery to me. Maybe some dumb thing like
insufficient PTYs or who knows what. But it's repeatable like
clockwork, ever since a few days ago.
Having gotten past that, for now, I proceeded to build the rest of the
distro, until...
Regarding #3:
When building serf-1.3.10, this warning foreshadows problems to come
later:
buckets/ssl_buckets.c:1193:9: warning: implicit declaration of
function 'CRYPTO_malloc_init'; did you mean 'CRYPTO_malloc'?
[-Wimplicit-function-declaration]
Later, when trying to link SVN, this linker error happens:
/usr/bin/ld: /home/nathan/ramdrive/svndev/prefix/serf/lib/libserf-1.so.1:
undefined reference to `CRYPTO_malloc_init'
collect2: error: ld returned 1 exit status
make[1]: *** [build-outputs.mk:1140: subversion/svn/svn] Error 1
make[1]: Leaving directory '/home/nathan/ramdrive/svndev/svn-1.14.x'
make: *** [Makefile:1845:
/home/nathan/ramdrive/svndev/objdir/svn-1.14.x/.compiled] Error 2
For several years, I have been self-building SVN with serf-1.4.x and
running the test suite successfully with that. I'm referring to serf's
branches/1.4.x, last changed rev r1845547.
IIRC this was suggested by Brane and it's on my TODO list to locate
that conversation in the archives to see whether that was for this same
reason.
Perhaps something can be backported to serf-1.3.x to solve this. It
manifests on recent Debian (DSahlberg reproduced this also [3]).
My machine:
$ uname -a
Linux box 5.10.0-26-amd64 #1 SMP Debian 5.10.197-1 (2023-09-29) x86_64 GNU/Linux
$ lsb_release -d
Description: Debian GNU/Linux 11 (bullseye)
FWIW (since this was asked) SVN's configure is being called with:
--enable-javahl=yes
--with-jdk
--with-jikes=no
--with-junit=/home/nathan/ramdrive/svndev/distfiles/junit-4.10.jar
(and many other options).
Thanks again to everyone for your help and patience! I feel like I've
finally made progress on a nagging issue that existed for a long time.
[1] https://colabti.org/irclogger/irclogger_log/svn-dev?date=2023-11-12
[2] https://colabti.org/irclogger/irclogger_log/svn-dev?date=2023-11-09
[3] https://colabti.org/irclogger/irclogger_log/svn-dev?date=2023-11-11#l137
Cheers,
Nathan
