[FFmpeg-devel] [PATCH] Rename ff_random_get_seed to av_*, export the header
Martin Storsjö
martin
Fri May 14 10:57:46 CEST 2010
On Fri, 14 May 2010, Benoit Fouet wrote:
> On Fri, 14 May 2010 11:00:29 +0300 (EEST) Martin Storsj? wrote:
> > On Fri, 14 May 2010, Benoit Fouet wrote:
> >
> > > On Fri, 14 May 2010 09:57:58 +0300 (EEST) Martin Storsj? wrote:
> > > > diff --git a/libavutil/random_seed.h b/libavutil/random_seed.h
> > > > index a954381..db4fe5d 100644
> > > > --- a/libavutil/random_seed.h
> > > > +++ b/libavutil/random_seed.h
> > > [...]
> > > > +#if LIBAVUTIL_VERSION_MAJOR < 51
> > > > +attribute_deprecated uint32_t ff_random_get_seed(void);
> > > > +#endif
> > > >
> > >
> > > I don't think this one should be added.
> > > The ffmpeg tree should be fixed instead.
> >
> > Yes, it is fixed in the second patch. But it is still needed after that.
> >
> > Current versions of libavformat link directly to this symbol, and if the
> > libavutil shared library is updated to a version without the symbol, the
> > older libavformat will fail to load.
>
> why ? It should link.
> You have defined the symbol, I just don't see why you should add a
> prototype for it.
Ah, you meant only the prototype, not the whole backwards compatibility
function as such, I misunderstood.
With the current compiler flags, you'd get a
libavutil/random_seed.c:48: error: no previous prototype for
'ff_random_get_seed'
error if the prototype is missing.
> > So for distributions shipping libav*
> > in separate packages, this is a must, unless we want them to always
> > enforce all libav* from the exactly same build...
> >
>
> Adding the ff_random_get_seed prototype is only to be able to build,
> not to link.
> Do we expect any version of libavfoo to be able to be built against any
> version of libavbar ?
No, of course not.
// Martin
More information about the ffmpeg-devel
mailing list