[Ffmpeg-devel] [PATCH] [Visibility] libpostproc public functions

Rich Felker dalias
Tue Sep 19 18:46:25 CEST 2006


On Tue, Sep 19, 2006 at 08:12:28AM +0200, Diego 'Flameeyes' Petten? wrote:
> On Tuesday 19 September 2006 08:17, Rich Felker wrote:
> > Yes there is. ISO C says behavior is undefined when multiple
> > translation units contain symbols with the same name, so any valid
> > program should not do this.
> On translation units, yes, but on libraries the behaviour is usually clear, 
> with interposing (I admit if this is a standard or only a de-facto 
> convention).

The reason for this convention is to partially mimic the behavior of
static libraries, where an object in the archive will only get pulled
in if it's needed to resolve undefined symbols. In this case you can
define your own versions of all the symbols that might be needed from
a particular .o file and prevent it from getting pulled in. However if
it does get pulled in for some other reason, you will get serious
errors!

Because this whole setup is so broken, the relevant standard libraries
(everything defined by C and POSIX) says that the behavior is
undefined if you declare an external symbol of your own having the
same name as one defined in the standard, EVEN IF YOU DON'T USE THE
ONE IN THE STANDARD YOURSELF since library functions might depend on
one another. User libraries should make the same convention. Declaring
a symbol that conflicts with any symbol used in libav* should be
considered a programmer error and not supported in any way.

> The problem is, this usually leads to conflicts anyway so it's 
> really borderline. I think only pthread libraries and Xorg relies heavily on 
> interposing,

LinuxThreads does because LinuxThreads is a broken hack. A proper
threads implementation is internal to the C library and does not even
need a separate -lpthread. LinuxThreads is also not portable. libav*
is supposed to be portable code, not GNU/Linux crap.

> although other things like dmalloc and other preloadable 
> libraries make use of this features.

Again this is not portable and any program that depends on it is
broken.

Rich





More information about the ffmpeg-devel mailing list