-- Leo's gemini proxy

-- Connecting to git.thebackupbox.net:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini

repo: blog
action: commit
revision:
path_from:
revision_from: 11a16378b3433213a65fc51b0d1c0df000869efd:
path_to:
revision_to:

commit 11a16378b3433213a65fc51b0d1c0df000869efd
Author: epoch <epoch@thebackupbox.net>
Date:   Mon Sep 11 09:06:05 2023 +0000

    veilid-3 was missing next-link and added notes about getting veilid-server running on enzo and THC segfault

diff --git a/veilid-3 b/veilid-3

--- a/veilid-3
+++ b/veilid-3
@@ -1,6 +1,7 @@
 # a kind of chat thing

 => veilid-2 previous post
+=> veilid-4 update

 since the last post, while I was reading more issues and stuff in the veilid repo
 => https://gitlab.com/veilid/veilid/-/issues/177 specifically, this one
diff --git a/veilid-7 b/veilid-7
new file mode 100644
index 0000000000000000000000000000000000000000..d36b510f50c3c880dddab96e9849c3aafea4ef26
--- /dev/null
+++ b/veilid-7
@@ -0,0 +1,65 @@
+# running it elsewhere
+
+=> veilid-6 previous
+
+## 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.
+=> https://thc.org/ THC
+=> https://www.thc.org/segfault/ 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
+=> https://github.com/rust-lang/libc/issues/2054 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.

-- Response ended

-- Page fetched on Sun Jun 2 10:51:07 2024