On Feb 17, 2013, at 19:16, Carl Eugen Hoyos wrote: > > Could one of you (who is affected by the problem, > remember that it cannot be reproduced on same > environments) please test mentioned patch? > > Your problem unfortunately will not be fixed as > long as you don't comment on the patch;-(
I'm not sure if you counted me among the affected people, but in fact I'm not. The static libraries I'm using for one of my projects are from an old FFmpeg version which predated the 'hack' that's biting Lars. And I've already commented on the patch. Myself I'd treat ff_log2_tab as its ff_ prefix imposes: have a static copy per library (or even module). It's small enough for that, and at least that approach doesn't introduce (another) dependency on the library in which the symbol is defined (libavutil I presume). It also does not increase the complexity of the configure process, nor add yet more conditional code. Simply replace log2_tab.c by log2_tab.h in which ff_log2_tab is declared as a static array, and include that header in every file where the constant is used. I must say that I'm a little bit surprised by the "we can't reproduce it here" attitude. Of course you can't validate the code on all hardware/software combinations, but I'd hope that you do check the shared libraries on a number of scenarios outside linking to ffmpeg, ffprobe etc. Anyway, I'm pretty sure that you're likely to encounter the same problem creating a monolithic shared library from the static libraries of, say, lavc, lavf and lavu . Because in doing that, the linker has to pull in every member of those static libraries (exactly as does the -all_load argument), and thus encounter the multiple definitions of ff_log2_tab . René _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
