[Libav-user] Dll Versioning

[Alex Cohn]

On Tue, Oct 30, 2012 at 11:04 PM, Don Moir <donmoir at comcast.net> wrote:
>>>> 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.

Thanks for mentioning delay loading, this is probably the most
reliable and clean technique if putting the dlls near executable is
not possible for one of the reasons you mentioned above, or for any
other reason.

Sincerely,
Alex