running it elsewhere

=> previous | next

segfault.net (no relation to SegFault my IRC bot)

I was looking at THC's stuff and found some like, dynamic containers thing they host.

=> THC | Disposable Root Servers

Following the usual install instructions got me to the point of:

$ veilid-server
Error:
   0: failed to set up journald logging
   1: No such file or directory (os error 2)

Disabling logging will keep that error from happening, which you do like this:

veilid-server -c loggin.system.enabled=false

Now you've got an easy to use second node for testing stuff. Which is what I used it for.

old 32-bit netbook

x86 hasn't really been something people target anymore for at least a few years now, but I've been using a netbook as my server for the last couple years.

I've been wanting to run stable veilid toys for public use, but have only been able to run veilid-server on my desktop because of the 64-bitterness.

First step is to get rust to target i686 from my x86_64 desktop. Can do this by doing:

$ rustup target add i686-unknown-linux-gnu
$ cd ~/projects/veilid
$ cargo build --target=i686-unknown-linux-gnu --release

If you don't include --release it'll make a HUGE binary with debug data in it... which you might want.

If I need to debug veilid-server, I'll rebuild it and send it over then trigger that error again. anyway.

I figured since rust kind of does monolithic builds, if I target i686, it should run fine, right? welp, not all the things get static'd in.

I got it built, and tried it out:

$ ./veilid-server
./veilid-server: /lib/i386-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./veilid-server)

tried to make it more static with:

RUSTFLAGS="-C target-feature=+crt-static" cargo build --release --target i686-unknown-linux-gnu

After that built I ran it again and it started up alright, but right after networking started happening it Aborted with:

Fatal glibc error: dl-call-libc-early-init.c:37 (_dl_call_libc_early_init): assertion failed: sym != NULL

My bet was something having to do with that one call I can't remember the exact name of that uses dlopen() and does something with address resolution.

I did get sidetracked thinking it might've been openpty related because I'd found that same error message

=> in some issue on github

opened veilid-server in gdb and ran it again and saw:

Thread 4 "tokio-runtime-w" received signal SIGABRT, Aborted.

but also, the 'bt' output showed it was inside of getaddrinfo() with some dl_ related things being done.

I also tried to build it using musl instead of glibc, but that failed in other fun ways at build-time.

Stuff like:

include/GFp/type_check.h:71:42: error: static assertion failed: "uint64_t is insufficient precision for n0"

I figured the easiest way to get this working would be to get the same version of glibc onto the target computer, which was also running debian, but it was still running oldstable.

oldstable is a good enough reason to update at least to stable, so I did that, and now the first cross compile attempt method worked fine.

I'll setup some toys and port forwarding and probably make another post about that when that's all done.