Diego Biurrun <di...@biurrun.de> writes:

> On Wed, Oct 10, 2012 at 11:22:00AM +0100, Måns Rullgård wrote:
>> Diego Biurrun <di...@biurrun.de> writes:
>> > On Tue, Oct 09, 2012 at 03:48:39PM +0300, Martin Storsjö wrote:
>> >> On Thu, 4 Oct 2012, Diego Biurrun wrote:
>> >> >The table is so small that the space gain is not worth the
>> >> >performance overhead of cross-library access.
>> >> >---
>> >> >
>> >> >Now with each duplicated table in a separate file.
>> >> >
>> >> >libavcodec/Makefile     |    1 +
>> >> >libavcodec/log2_tab.c   |    1 +
>> >> >libavutil/Makefile      |    1 +
>> >> >libavutil/log2_tab.c    |   30 ++++++++++++++++++++++++++++++
>> >> >libavutil/mathematics.c |   11 -----------
>> >> >5 files changed, 33 insertions(+), 11 deletions(-)
>> >> >create mode 100644 libavcodec/log2_tab.c
>> >> >create mode 100644 libavutil/log2_tab.c
>> >> 
>> >> This is used in libavformat as well, so that one also needs a copy,
>> >> if this is the way to go.
>> >
>> > Alternatively, we could make the table public.
>> 
>> What good would that possibly do?  I thought we were trying to get rid
>> of exported data symbols.
>
> I thought we were trying to get rid of semi-private and private symbols
> shared across libraries...

Yes, because they are troublesome when building DLLs.  Making them
public does nothing to mitigate those problems.

-- 
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to