[Libav-user] ff_log2_tab defined multiple times in the fmpeg 1.1 libraries, bug or feature ??

[Lars Hammarstrand]

2013/2/14 Hendrik Leppkes <h.leppkes at gmail.com>


> In any case, this patch was focused on shared library builds, and
> importing data symbols from shared libraries does add an extra level
> of indirection.
>

This problem is new to me, please tell me what os and run-time loader you
are referring to that has this issue. This may once have been a problem at
the time they started to use 16/32-bits MMU's (with segment programming aka
near and far pointers) like 15-20 years ago but this is absolutely not an
issue today. Bear in mind that the extra level of indirection you mention
is only "a single bit in the big binary cosmos" (:-) compared to what the
run-time loader is performing during normal work. Trying to optimized
things this way is what I would call sub optimization...


However, not only that, it would also require exporting a ff* private
> symbol from avutil, and adds a lot of complexity when dealing with
> shared library builds on some systems (eg. MSVC)
>

This is one part that I don't understand, what problem does MSVC have that
requires multiple definitions of the same global variable?  Btw, what do
you mean by "private" symbol in this case, private like in a class
definition or "static global in c" like  Linkages of
identifiers<http://stackoverflow.com/a/4239955>
 ?

Anyhow, there was an another case with exactly the same problem in
libavcodec v53.61.100  The global variable
ff_inverse[257] in libavutil/inverse.c was included
by libavcodec/inverse.c but has now moved into mathtables.c and is declared
in mathops.h (see below). AFAIK there has been no problem so far with for
MSVS.

libavcodec/mathops.h: extern const uint32_t ff_inverse[257];
libavcodec/mathtables.c: const uint32_t ff_inverse[257]={



> It may not do anything for static builds, but it also didn't cause any
> issues in sane build environments (all the ffmpeg applications still
> build fine for example), so it may as well be a problem on your end.
>

Nope, it's bad practice and you are only begging Murphy for problems ;-)
 But we really don't have to argue about it since there will soon be a
patch that will fix the problem according to Michael Niedermayer.

Regards, Lars.



> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130215/dab0341a/attachment.html>