[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