Issue
I noticed that constructors from shared objects linked into my applications will always run before my application constructors, even if my applications has lower priority number (ie: higher priority); for example, let's say this program:
#include <stdio.h>
static void __attribute__ ((constructor (101))) test() {
printf("test\n");
}
int main(int argc, char *argv[]) {
return 0;
}
is linking the following shared object:
#include <stdio.h>
static void __attribute__ ((constructor (102))) test_so() {
printf("test so\n");
}
I expected the output to be:
test
test so
Instead, the output is the opposite.
Is there any reason why? I could not find any documentation.
Solution
Is there any reason why?
Facts:
__attribute__((__constructor__))
basically adds a pointer to the function to some ELF section- Every ELF file has a separate DT_INIT or DT_INIT_ARRAY sections.
- Every ELF file is loaded in order, and dependencies are loaded before executable.
- So shared libraries constructors will run before executable.
- The ordering of
__attribute__((__constructor__(this_number)))
is limited to one ELF file, as compiler can reorder them there.
could not find any documentation.
It is documented in https://refspecs.linuxfoundation.org/elf/elf.pdf :
Initialization and Termination Functions
After the dynamic linker has built the process image and performed the relocations, each shared object gets the opportunity to execute some initialization code. All shared object initializations happen before the executable file gains control.
Answered By - KamilCuk