I have a situation where I distribute a library that uses symbol interposition to deal with some stdlib.h functions, e.g., malloc. I would normally just use the standard psymbol = dlsym(RTDL_NEXT,"symbol") technique as described here.
I have some users that want to build statically linked binaries though, and RTLD_NEXT isn't valid in that context---dlsym doesn't just fail in that context, it exits with RTLD_NEXT used in code not dynamically loaded. I can force these users to use the -Wl,--wrap,symbol methodology described here, and provide the appropriate __real_symbol,_wrap_symbol pair since they are using pkg-config to link to my library anyway.
It would be fine with me to always use the linker wrap solution, however I have a problem where one of my optional library dependencies (Open MPI) is also trying to wrap the same symbols, but is using the RTLD_NEXT approach---this appears to take precedence over the ld wrap option.
I can certainly implement both options, and statically select the dlsym approach when Open MPI is configured (Open MPI prevents -static linking anyway). The problem is that I'm not sure that this will be the only library trying to interpose on my symbols.
Is there a way that I can compile both options into my library (i.e., __real_symbol and __wrap_symbol for the -static link, and symbol and *psymbol for dlsym), force the -Wl,--wrap,symbol flags during static linking (through pkg-config --static --cflags), and dynamically check to see if RTLD_NEXT is currently available? This way I can build one library that works in both contexts.
