[FFmpeg-devel] [PATCH 11/11] Make ff_cmap_read_palette static to libavcodec/iff.c. Delete iff.h.

Diego Elio Pettenò flameeyes
Wed Jan 26 20:27:48 CET 2011


Il giorno mer, 26/01/2011 alle 12.00 -0500, Ronald S. Bultje ha scritto:
> 
> > the thing becomes complicated in case a major bump happens. in that
> case
> > it can happen that the library that was not bumped is still on the
> disk,
> > and applications that are linked to it still use it. In that case
> we'd
> > need to keep it until the next major bump.
> >
> > I don't see that this is the case here. Am I overlooking something?
> 
> What if people don't upgrade their SVN/git every day? It could be that
> people update from a specific point in time to a specific point in
> time where the above bug does happen. 

In this particular case, as any other particular case that is _not_
being used (and the list of symbols being used outside of the defined
av* interface is the one I sent before, this one is not in there), there
is no risk that mixing different libav* versions can cause linking
problems.

The problem you could have for instance with ff_dv_frame_profile which
is defined in libavcodec and used in libavformat; if we were to rename
that one, you _could_ have an older libavformat.so.52 build that used
this one, and if it was gone with newer libavcodec.so.52 you'd end up
with a missing symbol reference.

But if the upgrade happens at the same time, the fact that the old
libavformat.so.52 is still (unlinked) on disk and loaded by other
executables is not going to be an issue, since the corresponding
libavcodec would also already be loaded in memory.

In general, unless the symbol is in one of the two lists I sent last
week, we can kill them off without realistic effect on other projects or
old binary packages.

-- 
Diego Elio Petten? ? Flameeyes
http://blog.flameeyes.eu/




More information about the ffmpeg-devel mailing list