[vlc-devel] [vlc-commits] win64 packaging: distribute libstdc++-6.dll and libgcc_s_sjlj-1.dll
funman at videolan.org
Sun Nov 6 17:59:32 CET 2011
Rémi Denis-Courmont <remi <at> remlab.net> writes:
> > > Eh? What happens if another version of libraries with the same names
> > > exist in %SYSTEM64%
> > Not sure about that one, I could test it on a real system
The copy in VLC folder is used.
> > > or are already loaded in the current process?
> > http://msdn.microsoft.com/en-us/library/ms682586(v=VS.85).aspx
> > Before the system searches for a DLL, it checks the following:
> > If a DLL with the same module name is already loaded in memory, the
> > system uses the loaded DLL, no matter which directory it is in. The
> > system does not search for the DLL.
> > -> the copy in memory is used
> That reads like it will fail miserably if an application uses an older version
> of libgcc_s and then loads LibVLC.
s/loads LibVLC/loads a C++ VLC plugin/ , so in such a theoretical event one
could just delete all C++ plugins.
Or modify the application to load the dlls from VLC path (they load libvlc.dll
> > Anyway I expect libstdc++-6.dll to have a consistent ABI, just like
> > libstdc++-6.so
> Maybe stdc++ and gcc_s are sanely versioned. And fortunately, Windows always
> uses symbol versioning internally, does it not?
> But for other less stable libraries like libav, this sounds like a crazy bet.
More information about the vlc-devel