This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bergkvist
Recipients bergkvist, ned.deily, ronaldoussoren
Date 2021-07-22.12:43:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1626957807.83.0.0968111027152.issue44689@roundup.psfhosted.org>
In-reply-to
Content
You are absolutely right! From the manpage of dlopen(3) on MacOS Big Sur:

> dlopen() examines the mach-o file specified by path. If the file is compatible with the current process and has not already been loaded into the current process, it is loaded and linked.  After being linked, if it contains any initializer functions, they are called, before dlopen() returns. dlopen() can load dynamic libraries and bundles.  It returns a handle that can be used with dlsym() and dlclose(). A second call to dlopen() with the same path will return the same handle, but the internal reference count for the handle will be incremented. Therefore all dlopen() calls should be balanced with a dlclose() call.

Essentially, if the shared library contains initializer functions that have some kind of side-effects, dlopen will also trigger these side-effects.

Basic example:
```
// mylib.c
#include <stdio.h>
void myinit(void) {
    printf("Hello from mylib\n");
}
__attribute__((section("__DATA,__mod_init_func"))) typeof(myinit) *__init = myinit;
```

---
```
// main.c
#include <dlfcn.h>
#include <stdio.h>
int main(void) {
    void* handle = dlopen("./mylib.dyld", RTLD_LAZY);
    if (handle == NULL) printf("Failed to load"); 
}
```

$ clang mylib.c -shared -o mylib.dyld
$ clang main.c -o main
$ ./main
Hello from mylib
History
Date User Action Args
2021-07-22 12:43:27bergkvistsetrecipients: + bergkvist, ronaldoussoren, ned.deily
2021-07-22 12:43:27bergkvistsetmessageid: <1626957807.83.0.0968111027152.issue44689@roundup.psfhosted.org>
2021-07-22 12:43:27bergkvistlinkissue44689 messages
2021-07-22 12:43:27bergkvistcreate