[Ffmpeg-devel] Externally visible symbols without ff or av prefix
Måns Rullgård
mru
Mon Nov 13 15:21:08 CET 2006
Aurelien Jacobs said:
> On Mon, 13 Nov 2006 13:42:28 -0000 (GMT)
> M?ns Rullg?rd <mru at inprovide.com> wrote:
>
>> Aurelien Jacobs said:
>> > On Sun, 12 Nov 2006 21:36:26 -0500
>> > Rich Felker <dalias at aerifal.cx> wrote:
>> >
>> >> 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.
>
> That's an interesting idea ! And if a conflict still happens with that,
> it becomes trivial to change the prefix.
> We could even simply apply this method to all symbols which don't have
> a ff_ or av_ prefix. This would avoid changing all the sources and
> keep the code even more readable.
Applying to unprefixed symbols is a bad idea, since that would incorrectly
rename references to other libraries. Well, we could rename only those for
which we have a definition somewhere, but that gets much more complicated.
> But I have no idea how to achive this (some nm black magic maybe ?).
More like objcopy. I'll read some man pages and see if there's something
we can use.
--
M?ns Rullg?rd
mru at inprovide.com
More information about the ffmpeg-devel
mailing list