[FFmpeg-devel] Binary compatibility for MinGW generated dlls

Panagiotis Issaris takis.issaris
Mon May 14 15:01:15 CEST 2007

Hash: SHA1


I fear $subject alone was enough to get most developers on this list to
either ignore this message or prepare to flame me... ;-)

Currently, when building new versions of libavcodec using MinGW, the
generated dlls cannot replace the old ones without relinking the

This is because the compiler generates the .def files, which contain all
public symbols. GCC sorts these alphabetically and numbers them
likewise. This means that if a symbol is added which is alphabetically
not situated after all other preexisting symbols, the library will lose
binary compatibility.

I figured a solution for this could be to have a non-generated .def
file, where only the public API functions are listed in.

So, for example, for avcodec with major version number 51, a
avcodec-51.def could contain all public API functions, but not stuff
like MPV_*, DCT_common_init, h263_encode_init, mjpeg_close,
mpeg4_encode_mb, ... which is currently in there.

To enable adding new API functions and at the same time enable addition
of codecs, muxers or demuxers, these could be listed with some offset
behind the regular API functions f.e.:

cat avcodec-51.def
  avcodec_open @1
  avcodec_find_encoder @10
  avcodec_find_decoder @11
  [room for adding new API functions without breaking binary interface]
  aasc_decoder @1000
  adpcm_4xm_decoder @1001
  vp6_decoder @1080
  [room for adding more decoders]
  ac3_encoder @2000
  wmv1_encoder @2030
  wmv2_encoder @2021

With friendly regards,

PS: I am not very experienced in Windows related stuff, so, I might have
overlooked other simpler or better solutions...
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the ffmpeg-devel mailing list