<div dir="ltr">2013/2/14 Hendrik Leppkes <span dir="ltr"><<a href="mailto:h.leppkes@gmail.com" target="_blank">h.leppkes@gmail.com</a>></span><br><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><br></div>
In any case, this patch was focused on shared library builds, and<br>
importing data symbols from shared libraries does add an extra level<br>
of indirection.<br></blockquote><div><br></div><div><div><div>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...</div>
</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
However, not only that, it would also require exporting a ff* private<br>
symbol from avutil, and adds a lot of complexity when dealing with<br>
shared library builds on some systems (eg. MSVC)<br></blockquote><div><br></div><div style>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  <a href="http://stackoverflow.com/a/4239955">Linkages of identifiers</a> ?</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style><div>libavcodec/mathops.h: extern const uint32_t ff_inverse[257];</div><div>libavcodec/mathtables.c: const uint32_t ff_inverse[257]={</div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It may not do anything for static builds, but it also didn't cause any<br>
issues in sane build environments (all the ffmpeg applications still<br>
build fine for example), so it may as well be a problem on your end.<br>
<div><div></div></div></blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>Regards, Lars.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
</div></div></blockquote></div><br></div></div>