[FFmpeg-devel] [PATCH] lavc/aac: fix shared build failures with MSVC.

Ronald S. Bultje rsbultje at gmail.com
Fri Nov 9 20:08:12 CET 2012


Hi,

On Thu, Nov 8, 2012 at 11:08 PM, Hendrik Leppkes <h.leppkes at gmail.com>wrote:

> On Fri, Nov 9, 2012 at 4:44 AM, Ronald S. Bultje <rsbultje at gmail.com>
> wrote:
>
> > Hi,
> >
> > On Thu, Nov 8, 2012 at 7:42 PM, Ronald S. Bultje <rsbultje at gmail.com>
> > wrote:
> >
> > > On Thu, Nov 8, 2012 at 4:18 PM, Michael Niedermayer <michaelni at gmx.at
> > >wrote:
> > >
> > >> On Fri, Nov 09, 2012 at 12:09:56AM +0100, Clément Bœsch wrote:
> > >> > ---
> > >> >  libavcodec/aacenc.c       | 9 ++++++++-
> > >> >  libavcodec/libvo-aacenc.c | 9 ++++++++-
> > >> >  2 files changed, 16 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> > >> > index fe5b84d..22962a3 100644
> > >> > --- a/libavcodec/aacenc.c
> > >> > +++ b/libavcodec/aacenc.c
> > >> > @@ -811,6 +811,13 @@ static const AVClass aacenc_class = {
> > >> >      LIBAVUTIL_VERSION_INT,
> > >> >  };
> > >> >
> > >> > +/* duplicated from avpriv_mpeg4audio_sample_rates to avoid shared
> > build
> > >> > + * failures */
> > >>
> > >> please also add such a comment to avpriv_mpeg4audio_sample_rates
> > >> or maybe move the 2 lines of sample rates in a header and inlcude
> that.
> > >>
> > >> I naively assume that theres no clean solution without duplication
> > >>
> > >
> > > That assumption is wrong.
> > >
> >
> > More specifically,
> > http://fate.libav.org/i686-msvc-10-dll-wine/20121108195907 works fine?
> >
> > Ronald
> >
>
> But thats libav, and it doesn't have the sample rates in the AVCodec
> definition.
>
> The problem is that the dllimport marker is always present, so even if you
> use a datasymbol in the same library where it lives, the compiler/linker
> make it an imported symbol, which means its not constant, and thus cannot
> be used as a static initializer.
>
> A "clean" solution would be to define av_export conditionally, but that
> solution was apparently not liked, and instead the permanent define won.


I think we can do better than that. In fact, my original patch (which was
subsequently ""fixed"" by some other people) did exactly what you describe.
It shouldn't be hard to revive that behaviour and prevent this code
duplication?

Ronald


More information about the ffmpeg-devel mailing list