Description
What version of Go are you using (go version
)?
Anything (since the linker's -r flag was added in 2010 anyway)
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env
)?
Ubuntu 20.04, but really: any ELF system.
What did you do?
I maintain the Go snap, which is a "classic snap": classic snaps run in the same mount namespace as everything else but load dynamic libraries from a "core" snap, which is mounted at a path like /snap/core18/current. To do this, they need to have a DT_RPATH like /snap/core18/current/lib/x86_64-linux-gnu. The linker's -r option causes a DT_RUNPATH tag to be used, which doesn't work for the reasons explained in https://www.qt.io/blog/2011/10/28/rpath-and-runpath. (It almost works, but when glibc tries to load a NSS component, it loads it from the host not the core snap and that can break).
It would be a trivial change to the linker to add an option "-rpath-instead-of-runpath" or whatever, but would that be acceptable?