[rollcat]

For entire classes of applications, you can treat Linux as a black box. Things like syscalls, /proc & /sys, are all incredibly stable. So that's what Go does with its syscall package; it completely sidesteps libc, ld.so, and whenever it can, it just produces static builds - at least on Linux.

They tried to get away with it on OpenBSD, macOS, etc and got their hand chewed off.

[hedora]

There are a few reasons I avoid Go, and their syscall pacakge is on the list. It breaks a bunch of tooling that requires LD_PRELOAD or static linker interposition. (One example: Interposing on the clock to test timeout logic.)

I wish they had an option that just used libc. Maybe, someday someone will add a target architecture/port that just uses posix. I’d prefer that in Linux too.

[nolist_policy]

Intercept at the syscall level instead with seccomp. Like I'm doing here:

https://github.com/lukasstraub2/intercept-anything

Go is hardly the only thing where LD_PRELOAD doesn't work.

[rollcat]

That's not Go-specific, it's just how static linking works. As nolist_policy advised, it's more useful and precise to intercept programs at the syscall (rather than library call) boundaries. Programs are free to do all sorts of insane stuff, there was e.g. a Scheme interpreter that kept growing the stack until it caught SIGSEGV, at which point it'd run a compacting GC and reset the stack pointer. ¯\_(ツ)_/¯

Regarding LD_PRELOAD, I highly doubt that this is required by POSIX. macOS (which is a certified UNIX) uses DYLD_INSERT_LIBRARIES instead. OpenBSD (which is known for their pedantic documentation) uses LD_LIBRARY_PATH, doesn't mention any standards, and refers the reader to SunOS 4.0. If this is somehow standardised, I'd love to read the actual document.