[Ffmpeg-devel] [PATCH] Staticising mpeg12data header

[Rich Felker]

On Tue, Sep 19, 2006 at 08:11:08PM +0300, Uoti Urpala wrote:
> On Tue, 2006-09-19 at 17:54 +0100, M?ns Rullg?rd wrote:
> > It's not shared libs that are broken; it's C++.  We don't have a problem
> > with conflicting symbols, so we don't need a solution either.  I will not
> > be committing any build system changes related to this before seeing evidence
> > of a real problem.
> 
> Conflicting symbols are not the only issue. Number of visible symbols
> affects linking performance and public visibility of symbols affects
> runtime performance. When compiling shared library code without known
> visibility the compiler cannot know whether external symbols are in the
> same shared library or not, and so always has to address them indirectly
> through the global offset table. When the symbols are known to be in the
> same library that runtime indirection can be avoided.

Part of this can be solved without polluting the code using -Bsymbolic
linker option, which can easily be enabled from configure just on GNU
systems that support it. The fundamental problem however is that ELF
is broken. Its misguided attempts to define a behavior for conflicting
symbols rather than just treating them as a fatal error is what leads
to horrible big-O dynamic link performance. It's also broken in that
it doesn't require symbols (both imported and exported) to be sorted
in the binaries. The simple assumption that symbols are sorted makes a
much faster symbol resolution algorithm which doesn't even require
hash tables possible.

Anyway my point is that when the system is broken, you don't pollute
your codebase with OS-specific hacks to try to work around it. Instead
you either accept that it's broken (and the penalties that go along
with that) or fix it at the point of brokenness.

Rich