On Sun, Jul 05, 2020 at 05:08:51PM +0200, Tomas Härdin wrote:
> sön 2020-07-05 klockan 14:10 +0200 skrev Jan Engelhardt:
> > On Sunday 2020-07-05 13:39, Tomas Härdin wrote:
> > > > > Downgrading to a .so file with a lower minor version number than
> > > > > the program is built against can never be expected to work. Else
> > > > > we couldn't add new functions without a major bump.
> > > > 
> > > > It requires the use ELF symbol versions -- which ffmpeg fails to
> > > > do properly.[...]
> > > 
> > > This is a fair point. I didn't actually know the loader can do stuff
> > > like this, sounds super handy. How hard would it be to get that going?
> > 
> > Change libavcodec.v to
> > 
> > LIBAVCODEC_58 {
> >   global:
> >   av_foo;
> >   av_bar;
> >   av_whatever_else_there_is;...
> >   local:
> >   *;
> > };
> > LIBAVCODEC_58.91 {
> >   global:
> >   avpriv_mpeg4audio_get_config2;
> > } LIBAVCODEC_58;
> > LIBAVCODEC_58.123 { /* future example */
> >   global:
> >   avblahblah;
> > } LIBAVCODEC_58.91;
> > 
> > Repeat likewise for other .v files. The file is no longer a template. The
> > automatic substitution of "_MAJOR" by the build system needs to cease. 
> > Version
> > numbers in the file are supposed to be fixed (among the set of all .so files
> > that share a SONAME).
> 
> Interesting. This also makes what's changed between versions more
> explicit. Can this be checked by machine as well? Like having a post-
> receive hook that makes sure the .v files are consistent, or maybe have
> FATE check it somehow.

its possible to do some sanity checks at the git level that would catch some
issues.
(for example you can detect changed version numbers and reject if that doesnt
 also update APIchanges
 and then parse the change to APIchanges and the change to the .v file and
 check if the same functions and versions are listed.)
 
At the fate level it should be easier to detect the actual functions in the
object files and compare this to the .v files

so its all doable in theory, but at that point the question arises, can we
maybe generate this automatically from the APIchanges file if we decide to
do that.
APIchanges should list all added functions and the version numbers.


> 
> This probably needs to be passed through the technical committee. But I
> don't think it'll break the ABI like Timo suggests, if we bump minor at
> the same time.

the technical committee is for disagreement arbitraration.
ATM i dont think we have any disagreement

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to