On 22.09.2018 21:18, Sam wrote:
> I'm looking for a way to make my linker tell me that the executable it
> linked contains the same symbols as in one of the executable's shared
> libraries. Apparently this links fine, and the global symbols from the
> executable override the ones in the shared library,
This can be considered as a feature, not a bug. See a recent thread
"Knowing which function to call" how a program can potentially define
its own pow() function to override both pow() and std::pow() in one go.
Specifically, one Manfred posted the following in that thread:
"I don't think it is undefined behavior, it is a matter of function
replacement instead (20.3.19 and 20.5.4.6). The program creation process
(5.2, p.9) specifies that library linkage is performed last, so that all
extern function definitions provided by the program itself are used
instead of the library supplied ones."
> and not just for
> references in the executable itself, but also any references in the
> shared library.
This is certainly implementation-dependent. For example, with Windows
DLL-s it is always known from which DLL the symbol is imported, so such
late rebinding does not happen. This means for example that one cannot
free() a block of memory allocated by malloc() in another DLL if they
are linked against different C runtime library versions.
In Linux, the dynamic loader attempts to behave more like the static
linking process where there is normally just a single instance of a
symbol in the final executable. This is sometimes good and sometimes
bad. Anyway, this is the mechanism by which some memory diagnostic tools
override malloc/free globally. The LD_PRELOAD mechanism is also often
used for injecting symbols in a process.
So this is a feature, not a bug :-) But Linux tools are typically
infinitely configurable so there might be some way to make them behave
the way you like. For example, there is
__attribute__((visibility("hidden"))); also dlopen() has some
interesting flags like RTLD_DEEPBIND.