On 04/03/2013 11:02 AM, Alexander Ivchenko wrote: > Thank you for your answers, seems that the question about the reason > with default -Bsymbolic is still open.. we are not clairvoyant, but it > is implemented in GCC so we should understand the reason :)
I suppose so, but we always follow the platform ABI, whatever it is. Doug Kwan was the original author. > Having that in mind, we have: > 1) All shared libraries for Android are built with -Bsymbolic > 2) Dynamic loader throws an error if we are doing COPY relocation > against DT_SYMBOLIC libs. > > So any COPY relocation is doomed to failure.. Ard, what was the reason > for introducing the support of this type of relocations in dynamic > loader in the first place? Well, I could opine that the true breakage is copy relocs, not -Bsymbolic. Copy relocs are an ingenious solution to a problem, but they're a kludge. -Bsymbolic allows you to do something that's not strictly compatible with Standard C/C++, and it's somewhat risky. However, it's not really a terrible idea for shared libraries directly to reference their own data, and for executables to reference the data in the shared library. The linker doesn't only link C programs, and not all languages have the one definition rule. One could also argue that -Bsymbolic and PIC can be safer, because it doesn't bind the size of a data symbol at compile time. Andrew.
