Hi, 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 :)
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? > range of the executable proper. However, a library built with > -Bsymbolic resolves all its internal references at build time, so any > reference held by the library itself is not preemptible, resulting in > two live instances of the same symbol. I totally agree that it is potentially dangerous situation and dynamic loader must somehow let the user know about that (btw linux dynamic loader silently allows copy against DT_SYMBOLIC). thanks, Alexander 2013/4/3 Andrew Haley <a...@redhat.com>: > On 03/29/2013 06:55 PM, Alexander Ivchenko wrote: > >> When compiling a shared library with "-mandroid -shared" the option >> -Bsymbolic for linker is turned on by default. What was the reason >> behind that default? Isn't using of -Bsymbolic somehow dangerous and >> should be avoided..? > > Yes indeed, -Bsymbolic is dangerous. > >> (as e.g. is explained in the mail from Richard >> Henderson http://gcc.gnu.org/ml/gcc/2001-05/msg01551.html). >> >> Since there is no (AFAIK) option like -Bno-symbolic we cannot use >> -fno-pic binary with COPY relocations in it (android dynamic loader >> will throw an error when there is COPY relocation against DT_SYMBOLIC >> library..) > > Sure, that's true. If a library is built with -Bsymbolic then you > must build executables PIC. That's just how it is. > > As to why Android turned it on by default -- we are not clairvoyant! > :-) > > Andrew. >
