[FFmpeg-devel] Problem building shared libraries using svn-r11100+ on x86_64
Nicolas George
nicolas.george
Tue Dec 4 21:30:01 CET 2007
Le quartidi 14 frimaire, an CCXVI, Michael Niedermayer a ?crit?:
> a patch which adds -Bsymbolic to the linker flags is welcome
What about adding
__attribute__(( visibility ("protected") ))
on the relevant variables? That fixes the problem too (I can submit a
patch), and it avoids changing the whole linking scheme of the library.
Furthermore, since the file is already full of GNUisms, adding some more is
not a problem.
Regards,
--
Nicolas George
(Before I found the simplicity of that solution, I wrote a lengthy
discussion about the problem. I leave it here for documentary purposes:)
- When building a shared library, references to globals must go through an
indirection. The compiler is informed to do so by the -fPIC option; it has
a small performance hit, so it is not the default.
- On i386, GNU ld is able to link shared libraries even if the code is not
relocatable, but this is a hack very architecture-specific, and can not
work on other architectures, especially not x86_64.
- The MMX dsputil code uses a bunch of big constants. Recently, that code
has been spread across several files, and the constants have been made
global.
- These constants are used from assembly snippets, where the -fPIC option
has no effect. And the access to the constants is not at all -fPIC-like.
- The suggested fix, -Bsymbolic, will link tightly all references to globals
inside the library: if the reference and the referee are both in the
library, the produced code will be similar to a reference to a static
variable in the same file.
- A visible change with -Bsymbolic is that the main binary can no longer
override symbols in the library for the library itself. This may or may
not be a problem. In particular, this may or may not break existing
programs. Anyway, this is a big change.
More information about the ffmpeg-devel
mailing list