On Tue, Oct 29, 2013 at 09:58:25PM +0100, Andy Polyakov wrote: > Another thing: run-time selection from among multiple pthreads implementations can only safely be managed by the RTLD, and dependencies on pthreads must still be declared via the linker-editor.
Libraries should be able to refer to pthread_* symbols and still use the run-time-selected pthread implementation *even* if the library was linked with -lpthread (and therefore a specific libpthread.so compilation symlink). If an OS delivers two (or more) pthreads implementations then: - if the ABIs of those pthreads implementations all match then the RTLD should be able to substitute any of them regardless of which libpthread any one object in the process was linked with; (e.g., via LD_PRELOAD, different library search paths, ..., but all the libpthreads would have to have the same SONAMEs and symbol version numbers) - but if their ABIs are not compatible then no run-time substitution is safe, no matter what the mechanism. (unless compatibility shims are involved, but then we *really* must leave it all to the RTLD and we can't be using dlsym() or weak symbols) I don't think libraries should be failing to declare their dependencies and then use dlsym(RTLD_DEFAULT) and dlopen()+dlsym() as a way to run-time link-edit-load their undeclared dependencies. Doing so is fundamentally racy and so would have to be done in .init sections, and results (which pthread gets used) would be unpredictable (since that would depend on object load and .init firing order). Plus we'd lose observability via ldd(1). I can't see any way to justify this without having examples of OSes where this is the documented way to handle dynamic linking against libpthread. But maybe I'm missing something? Nico -- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
