[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