3 ms·

Thank you for the hint about dlmopen! I had a problem that can be solved by loading multiple copies of a DLL, and it looks like reading manpages of the dynamic

by unnah 4y ago

Thank you for the hint about dlmopen! I had a problem that can be solved by loading multiple copies of a DLL, and it looks like reading manpages of the dynamic linker would have been a better approach than googling with the wrong keywords.

girfan 4y ago
That's great! There are a few cases where `dlmopen` has issues, for example, some libraries are written with the assumption that there will only be one of them in the process (their use of globals/thread local variables etc.) which may result in conflicts across namespaces. Specifically, `libpthread` has one such issue [1] where `pthread_key_create` will create duplicate keys in separate namespaces. But these keys are later used to index into `THREAD_SELF->specific_1stblock` which is shared between all namespaces, which can cause all sorts of weird issues. There is a (relatively old, unmerged) patch to glibc where you can specify some libraries to be shared across namespaces [2]. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=24776#c13 https://sourceware.org/bugzilla/show_bug.cgi?id=24776#c13 [2]: https://patchwork.ozlabs.org/project/glibc/patch/20211010163836.14666-8-vivek@collabora.com/ https://patchwork.ozlabs.org/project/glibc/patch/20211010163...