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

[Måns Rullgård]

Aurelien Jacobs said:
> 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.

Very true.

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

Well, vp56_decode_frame is better than 'inverse'.  Then again, using a common
prefix for all external symbols across the entire library is probably a good
idea.

>> 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_ ?

We could do some post-compile symbol mangling and rename all ff_* symbols
to something with a longer prefix less likely to conflict, while still
keeping the code readable.

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

Doing it just for the ffmpeg libs shouldn't be too difficult.  Tracking
all dependencies does seem a bit laborious.

-- 
M?ns Rullg?rd
mru at inprovide.com