Brian Peschel wrote: > >> >> 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. > Is there an option on the linker to at least warn me it is doing this? It's not doing anything wrong. If you have a bunch of libraries with the global symbol foo, they all end up referring to the same symbol. This is perfectly normal C/C++ behaviour, as the standards say: there can only be a single copy of a variable called foo in a running program unless that variable is declared static. People writing shared libraries need to be careful about namespace control. These days this is pretty easy, at least in C++ with namespaces. > I understand why it is happening now (thanks!) at least. But I am > worried about this same problem elsewhere. I expect this could happen > to me with 3rd party libraries I use. And unless a crash happens (like > it did in this case with my own libraries), it would be difficult to > diagnose. Quite possibly, but this is so common that you'd get a ton of spurious warnings. For example, some threads libraries redefine many system functions. Andrew.
