I've checked and you're right.
```
]==> cat t1.cxx
#include <iostream>
struct t1 {
t1() {std::cout << "constructing t1" << std::endl;}
~t1() {std::cout << "destructing t1" << std::endl;}
};
static t1 _t1;
]==> cat t2.cxx
#include <iostream>
struct t2 {
t2() {std::cout << "constructing t2" << std::endl;}
~t2() {std::cout << "destructing t2" << std::endl;}
};
static t2 _t2;
]==> cat t3.cxx
#include <iostream>
struct t3 {
t3() {std::cout << "constructing t3" << std::endl;}
~t3() {std::cout << "destructing t3" << std::endl;}
};
static t3 _t3;
]==> cat test.cxx
#include <dlfcn.h>
#include <iostream>
#include <cstdlib>
void atexit1() {
std::cout << "atexit1" << std::endl;
}
void atexit2() {
std::cout << "atexit2" << std::endl;
}
void atexit3() {
std::cout << "atexit3" << std::endl;
}
int main(int argc, char **argv) {
atexit(atexit1);
dlopen("./libt1.so", RTLD_NOW|RTLD_NODELETE);
atexit(atexit2);
dlopen("./libt2.so", RTLD_NOW|RTLD_NODELETE);
atexit(atexit3);
dlopen("./libt3.so", RTLD_NOW|RTLD_NODELETE);
return 0;
}
]==> g++ -shared -fPIC t1.cxx -o libt1.so
]==> g++ -shared -fPIC t2.cxx -o libt2.so
]==> g++ -shared -fPIC t3.cxx -o libt3.so
]==> g++ test.cxx -o test -ldl
]==> ./test
constructing t1
constructing t2
constructing t3
destructing t3
atexit3
destructing t2
atexit2
destructing t1
atexit1
```
I was confused because I read a lot of glibc's code recently and it essentially calls `main` like this:
```
exit(main(...));
```
See: https://sourceware.org/git/?p=glibc.git;a=blob;f=csu/libc-start.c;h=f4aa01a988994b274c0e792345ca8bbbcc6a475f;hb=HEAD#l320
And `exit` just calls the `atexit` handlers and quits. See: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/exit.c;h=9d3c5f48dfe1885a35e6a0a70e66275ddc19d3ef;hb=HEAD#l102
Therefore, the only way for all this to work this way is for `dlopen` to register its own `atexit` handlers, but I haven't seen anything like this when I skimmed thorough this code. Do you know what is the justification for doing it this way? I mean the order of implicit dlcloses and atexit handlers.
Anyways, I learned something new, thanks! And sorry for the noise.
---
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/338#issuecomment-195476112
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
