[Libav-user] Dll Versioning

[Alex Cohn]

On Tue, Oct 30, 2012 at 3:27 PM, Mark Kenna
<mark.kenna at sureviewsystems.com> wrote:
> On 30 October 2012 13:21, Alex Cohn <alexcohn at netvision.net.il> wrote:
>>
>> On 30 Oct 2012 15:01, "Mark Kenna" <mark.kenna at sureviewsystems.com> wrote:
>> >
>> > On 30 October 2012 10:55, Mark Kenna <mark.kenna at sureviewsystems.com>
>> > wrote:
>> >>
>> >> On 30 October 2012 10:51, Nicolas George
>> >> <nicolas.george at normalesup.org> wrote:
>> >>>
>> >>> Le nonidi 9 brumaire, an CCXXI, Mark Kenna a écrit :
>> >>> > I am trying to find a way of allowing my application to be able to
>> >>> > load
>> >>> > multiple versions of the FFMpeg DLL's at the same time.
>> >>>
>> >>> Why would you want to do that?
>> >>>
>> >>> The simplest solution to your problem is probably to find out how not
>> >>> to
>> >>> need it.
>> >>>
>> >>> Regards,
>> >>>
>> >>> --
>> >>>   Nicolas George
>> >>
>> >> I need to do that because we constantly find ourselves having
>> >> FFMpeg-based modules which overwrite our .dll files with older versions
>> >> causing serious crashing. I just need to be able to stop "drop-ins" from
>> >> interfering with the version that we are running.
>> >>
>> >> Thanks,
>> >> Mark.
>> >>
>> >
>> > I have also explored the option of statically linking the libraries but
>> > this is not possible in MSVC++ right? Surely there has to be a way to do
>> > this!
>> >
>> > Mark.
>>
>> 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.

BR,
Alex

>
> Thanks,
> Mark.