Sanitizers and static linking

I am guessing that sanitizers are not supported with static linking.
The AddressSanitizer document says so explicitly but the others do not.
Yet the interceptors use dlsym to set up certain system calls, so by
definition they can't support static linking.

Given that sanitizers won't work with static linking, why are static
libraries created for them?

Should there be an error check in the interceptor code for dlsym
returning nullptr? I just spent a bunch of time tracking down a problem
that turned out to be dlsym returning nullptr due to static linking.

It seems like either users should not be able to link sanitizer runtime
when linking statically or there should be a runtime check that dlsym
doesn't return nullptr. Ideally both.


Saying that sanitizers “do not support static linking” seems strange because we strongly advise users to link the sanitizer libraries themselves statically. This gives the best user experience, because it puts the interceptors into the executable, so they always come first in dynamic symbol search order.

What I think you are saying is that the sanitizers do not support linking statically with libc. This is probably true. It would be difficult to modify the interceptors to work when libc is linked statically, so it’s probably not supported.

Hopefully that explains why the sanitizer libraries are static, but they don’t exactly support linking with -static.

Ok, that makes sense. Should there be code to test the result of dlsym
and report an error to the user? Faulting simply because one uses
--static during the link stage isn't very friendly. It would be nice to
get an error with a helpful message about linking libc dynamically.

Would there be interest in a patch to implement this?


Reid Kleckner via llvm-dev <> writes:

I think so. I’d CC Matt Morehouse on it.