|
Just adding as a note here that we ran into this in the Node driver when we wanted to do testing in the same suite with both the shared library and libmongocryptd. Our workaround is to run the suite in different processes for each, but we still run into this when testing behaviour of the shared library for valid/invalid scenarios - once the shared library is loaded once and we try to load with different parameters the original shared library is still loaded.
|
|
Yeah, that’s absolutely possible, I didn’t try Windows for this. 
|
|
That's definitely not what I expected. I will investigate. (I believe Window's LoadLibrary still does this, though, since it cares about filenames instead of SONAMEs.)
|
|
colby.pike@mongodb.com You mean like this?
$ cat test.c
|
#include <dlfcn.h>
|
#include <stdio.h>
|
|
void dummy_so_shared_object_is_not_empty() {}
|
|
#ifdef MAIN
|
int main() {
|
void* handle_1 = dlopen("/tmp/test.so", RTLD_LOCAL | RTLD_LAZY);
|
fprintf(stderr, "handle_1 = %p (%s)\n", handle_1, dlerror());
|
|
void* handle_2 = dlopen("test.so", RTLD_LOCAL | RTLD_LAZY);
|
fprintf(stderr, "handle_2 = %p (%s)\n", handle_2, dlerror());
|
}
|
#endif
|
$ gcc -fPIC -shared -o test.so test.c && gcc -DMAIN -o test test.c -ldl && ./test
|
handle_1 = 0x55d362d722c0 ((null))
|
handle_2 = (nil) (test.so: cannot open shared object file: No such file or directory)
|
|
|
IIRC, LoadLibrary() on Windows has the same "helpful" behavior based on the filename of the library, so it will at least be consistently foolish.
|
|
I had a suspicion that I ran into this but was unsure if it was really what I was seeing.
I believe this is just the way dlopen() works when you provide only a filename. Because you have previously loaded a DSO with a filename (SONAME?) Foo, even if using a qualified path, subsequent attempts to "search" for a DSO using only the filename Foo will hit an in-process lookup table that matches the filename (SONAME?) of the prior loaded DSO and so the "system search" immediately resolves to the previously-loaded DSO.
|
Generated at Thu Feb 08 09:08:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.