[Ffmpeg-devel] Externally visible symbols without ff or av prefix

Rich Felker dalias
Mon Nov 13 03:36:26 CET 2006


On Sun, Nov 12, 2006 at 03:25:22PM +0100, Aurelien Jacobs wrote:
> > I'm actually quite angry at the GCC folks for
> > introducing these hacks because it means ignorant developers will use
> > the hacks rather than fixing namespace issues, and in turn will make
> > their software fail miserably on non-GNU-ish systems.
> 
> Ok, but it seems no one has anything better to propose. Do you ?

Yes, writing clean code. Most symbols should have static linkage and
the few that don't should have names that clearly identify the
library/codebase/module they belong to.

> Adding a prefix to symbol names don't fix the problem. It only reduce
> the probability of name colision, but this probability won't ever
> drop to 0.

The question is not the probability, but rather who's doing something
unreasonable when the conflict arises. If the name is something like
"permute_entries" then the library is probably doing something
unreasonable. If the name is "ff_internal_permute_entries" or
something, then the application is almost surely the one doing
something nonsensical if there's a conflict...

In any case, a well-documented library should document all the symbol
names it uses or reserves for itself, and should not pull in other
library dependencies without also documenting that fact and
documenting what symbol names they reserve.

> The best solution right now seems to be to simply ignore potential
> name colision unless a real colision happens. And then rename the
> faulty symbol (hopping the new name won't introduce a new collision).

Um, no, this is NOT a good solution. If a project follows this
philosophy, then when it goes unmaintained and a conflict eventually
does turn up, there will be no official fix. I actually encounted a
problem like this once -- IIRC Debian's libSDL was linked to some
libsoundfile crap, and libsoundfile in turn had hundreds of
trivially-named external symbols (3-letter names even!!) which were
conflicting with a piece of software I wrote which was being linked to
SDL.

Rich





More information about the ffmpeg-devel mailing list