2013/2/14 Hendrik Leppkes <[email protected]>
> 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user >
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
