[Libav-user] Dll Versioning

[Mark Kenna]

On 30 Oct 2012, at 21:25, Alex Cohn <alexcohn at netvision.net.il> wrote:

> 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
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

I am currently working on a method of renaming the dll's by adding a
version identifier. This involves changing the dll imports and lib
files though. I am very interested in the tool you created to
accomplish this. Maybe I could obtain a copy to see if I'm on the
right track?

Mark.