On 25/04/15 03:09, Andrew Stuart wrote:
OK getting somewhere now - working my way through the compilation issues
slowly.
Most of the compilation errors that I am hitting appear to be cross compilation
nuances relating to things supported on NetBSD but not Linux - fixing them
seems to involve working out if the error relates to something not supported on
NetBSD and looking for a configuration option to switch that subsystem to
something that is NetBSD compatible. For example switching from epoll to
kqueue. I’ve gotten through four or five roadblocks so far.
Right, if the software in question does not support cross-compilation,
you'll be in trouble. I guess the quickest way to hack around it is to
build everything on a NetBSD system, that way it's "accidentally"
cross-compiled to the right env. It's not very convenient, though.
The non-quick ways are documenting these issues when you run into them
and eventually us coming up with a packaging system which we can use to
host cross compilation fixes before we manage to push them upstream.
I’m stuck now on:
/usr/bin/ld: cannot find -lkvm
This appears to be saying it needs the NetBSD kvm (headers? library?). I can’t
find how to get them and inetgrate them into the build process. The stuff I am
reading says that Linux kvm is not related to NetBSD kvm.
Any hints to get me past this block would be appreciated.
kvm (in BSD context) is used to access kernel virtual memory, with the
common use case being pulling data structures to userspace by traversing
kernel memory directly starting from some symbol name. It's used a bit
like procfs in Linux, except that data isn't converted to ascii.
These days (well, since ~10-15 years ago), sysctl() is used more
commonly for pulling kernel data structures into userspace, since it
doesn't require giving a process full access to kernel memory. However,
retrieving the same information directly via memory is still supported
for the benefit of kernel core dumps (you can run ps(1) on a core file etc).
Rump kernels don't support the memory groveling aspects of kvm. I'm not
sure if there's any fundamental reason why it couldn't be supported --
just need the symbol list which we already have in some envs -- but it
would require writing some code. However, the sysctl part of kvm should
just work (not that sysctl is really a part of kvm, but with enough
history everything tends to get confusing).
So, to make a long story not that much shorter, uwsgi appears to be
using libkvm to retrieve the process list. While that is done using
sysctl, the high level interface is still provided by libkvm, and that's
why uwsgi is trying to link using -lkvm.
I'll add libkvm to the list of libraries provided by rumprun after some
testing (and some breakfast) and send an update to this list.
