Was going to edit the original post, but was easier to do a new one.

Went back to this again recently to make some better changes (did not mean to take two months… sigh) and it wouldn’t build! I’d either completely forgotten some of the steps I took last time or the build has changed a bit? Note that even though my changes are still on HammerDB 5.0 that doesn’t mean there haven’t been upstream changes - The HammerDB source code you obtain from Github is more like a “build system” as opposed to the actual source you are compiling. When you build from source you are actually running Tcl scripts that download source code from the TPC/HammerDB website and then it builds that.

Anyway, further to last time ended up doing this:

  1. Turns out I did need to do this bit:

     sudo ln -s /usr/pkg/bin/python3.12-config /usr/pkg/bin/python3-config
  2. Running a ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt update would fail because the Makefiles wanted to use -ldl which isn’t applicable for (Net)BSD. So instead I stepped through the process manually:
    1. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt extract.
    2. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt configure.
    3. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt compile.
    4. Which would then fail, but I could edit the relevant Makefile and remove the -ldl and re-run the compile and repeat this until all components had built.
    5. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt distribute.
    6. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt finalize. Weirdly, even though I’m sure these are the same steps update does, this didn’t copy all the required libraries into the distributions so I had one final step of:
    7. ./Build-Linux.sh x64 Setup/HammerDB-Linux.bawt update.

  3. That got me working Dev builds again. I also had a play about withstrace/dtrace/ktrace on the Prod builds and figured out they were actually fine, it was just looking for the libraries in an odd place; Say I had extracted at /home/me/temp/HammerDB-5.0, well, it was looking for /home/me/temp/lib. So I just copied the lib folder from a Dev build to that location and then the Prod builds would run fine; I started with strace just for ease of use, but the version on NetBSD is old and doesn’t print full filepaths which makes it useless. ktrace and kdump are pretty easy to use as well, but only if you know what you are looking for upfront and I didn’t, whereas dtrace is more complex, but I could get it to put all filepaths for HammerDB and eyeball a non-existent one:

     syscall::stat:entry, syscall::lstat:entry, syscall::access:entry
 /execname == "hammerdb"/
 {
     self->path = copyinstr(arg0);
     self->probe = probefunc;
 }
 syscall::stat:return, syscall::lstat:return, syscall::access:return
 /execname == "hammerdb" && self->path != NULL/
 {
     printf("%d %s %s errno=%d\n", pid, self->probe, self->path, errno);
     self->path = 0;
 }

Next for me on this: Figuring out a better Makefile fix so that’s less tedious to do. And it might not be impossible to do a Pkgsrc package for this since the separate steps (extract, configure, etc) would align with Pkgsrc.