[Libav-user] Dll Versioning

[Don Moir]

>>> Have you read a similar recent discussion on stackoverflow(
>>> http://stackoverflow.com/questions/11701635/use-ffmpeg-in-visual-studio)?
>>>
>>> Today zeranoe archives include version number in the dll names. Are you
>>> using a different source of precompiled Windows binaries?
>>>
>>> Anyway, it's good practise to install the DLLs in your app directory, next
>>> to the executable that will load them, and not in a shared directory where
>>> other applications could override them or be hit because your installation
>>> overwrought the files they relied upon.
>>>
>>> BR,
>>> Alex
>>
>> I've seen that link, it describes how to dynamically link rather than
>> statically link. Also, some of the file name's in the automated builds are
>> not incremented so older version will break them (swscale for example).

>Fair enough.

>> Statically linking so that I no longer require the .dll files at runtime
>>would solve my issue, the other alternative is to try and change the PE to
>> reference modified filenames (which is crazy).

>The other alternative is to deploy your preferred versions of the
>dynamic libraries to a private directory of your application. Unlike
>Unix, you are guaranteed that the system loader will prefer to pick up
>the DLL files that are in the same directory as the executable that
>needs them.

I had to go round and round with this a few times. A static link would be best but as I undertand it, it may not work. I have not 
tried it personally and you can find some info about that on zeranoe. Outside of ffmpeg I static link other libraries. If someone is 
successful static linking using ffmpeg under windows and using MSVC please let us know.

o - it's not always possible to put the dlls in the same place as the application. This has to do with the application might be a 
dll and being used as a plugin. Then the calling application will also think the ffmpeg dlls should also be listed as plugins.

o - I created a utility that will rename the dll's and all refereneces in the lib and dll's. Beware of the rules for renaming the 
ffmpeg dll's. This is useful if the names of ffmpeg dlls change and you don't want to build acummulation of old dlls. Also useful if 
you want to indentify the ffmpeg dlls are part of your app. The utility is something thats a raw development tool and not intended 
to hand out but email me on it if interested.

o - If you can't put the dll's in the same directory as the application for some reason, then use a subdirectory or some specific 
application directory. In this case you can use LoadLibrary but beware loading all the ffmpeg functions can eat memory and so best 
to use some kind of thunk for it. An alternative is to use an interface dll which you do a LoadLibrary on that links to the ffmpeg 
dlls. Now before you to do LoadLibrary on interface DLL, add to the DLL search order by calling SetDLLDirectory.

You can also try using delay loading which gives you the oportunity to change on the fly, where to look for your dlls.

http://msdn.microsoft.com/en-us/library/151kt790.aspx