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

[Aurelien Jacobs]

On Sun, 12 Nov 2006 21:36:26 -0500
Rich Felker <dalias at aerifal.cx> wrote:

> 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

If a.c and b.c can both be disabled independently, and both use functions
from c.c, you simply can't use static. Except if you
  cat c.c a.c b.c > all.c
and add some #ifdef in all.c to ensure only the needed parts are compiled.
But I doubt that a `cat libavcodec/*.c > lavc.c` would be very welcomed
(I won't even talk about the gigabytes of RAM that gcc would require to
compile this ;-).
So writing clean code require using extern linkage.

> and the few that don't should have names that clearly identify the
> library/codebase/module they belong to.

Is there a strong definition of "names that clearly identify..." ?
Does vp56_decode_frame match this definition ?

> > 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.

Sure.

> 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...

Why ? Isn't the application allowed to link to lavc and ffRadiusLib [1]
and libffjs [2] at the same time ? Why wouldn't those lib use the ff_
or ff_internal_ perfix too ? And if a conflict happens, who is wrong ?

Well, it seems that ff don't "clearly identify" ffmpeg. Maybe a prefix
such as ffmpeg_libavcodec_ would be safer, but it would be somewhat
painful to use. Maybe fflavc_ ?

> 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.

For sure this would help.
But I fear this would be a pain to maintain.

> > 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.

Good point. Let's hope ffmpeg won't ever get unmaintained.

Aurel

[1] http://fabrizio.oasi.asti.it/projects/ffRadiusLib/
[2] http://fforw.de/ffjs/