Brian Peschel <brianp@xxxxxxxxxx> writes: > I have a class that is in the shared library only (DBI), that calls a > method in SqlQuery. There is a method of the same name and parameters > in the shared and static library: void clear(std::string& query). That is a violation of the C++ One Definition Rule. Your program is erroneous, but the compiler is not required to diagnose this error. > I build the shared library without any reference to static library. I > build the static library without any reference to the shared > library. My program links both the shared and the static library into > them without any errors or warnings about symbol clashes. > > When I run my program calls a method in the DBI class (which is in the > shared library), it crashes. Using gdb, the crash appears to be in the > SqlQuery in the static library, not the shared library. Which makes no > sense to me, as the libraries were built without any reference to each > other. I can repoduce this every time with 2 different code paths, > both eventually calling a common method. > > If I add a namespace to the SqlQuery class in the shared library, the > crash does not occur. But my code base is well over a millions lines > of code and trying to do this everywhere a potential issue may be a is > a daunting task. I have other common class names (and method > definitions) that aren't causing crashes, but at this point, I am not > sure they are calling the correct methods either. > > Any ever heard of something like this? I am assuming it is some sort > of linker problem. But I don't understand why I am not getting > warnings about shared symbols. You get no warning because ELF linkers support symbol interposition. In your case, the symbol defined by the static library becomes a symbol defined in the main executable. There is, by default, a single global namespace of symbols defined in the main executable and in shared libraries. When the executable and a shared library both define the same symbol, the one in the executable takes precedence. All references in the shared library to that symbol become references to the symbol definition in the executable. This is not an error. ELF works this way because it means that if the executable defines "malloc", the shared libc will call the "malloc" defined in the executable, rather than calling its own malloc. This is considered to be a feature. You can adjust this default behaviour in various way, primarily by using symbol visibility. Ian
