Re: [Android] The reason why -Bsymbolic is turned on by default

[Andrew Haley <aph at redhat dot com>]

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.