[vlc-devel] [vlc-commits] win64 packaging: distribute libstdc++-6.dll and libgcc_s_sjlj-1.dll

[Rémi Denis-Courmont]

Le dimanche 6 novembre 2011 18:11:30 Rafaël Carré, vous avez écrit :
> Le Sun, 6 Nov 2011 10:14:56 +0200,
> 
> "Rémi Denis-Courmont" <remi at remlab.net> a écrit :
> > Le dimanche 6 novembre 2011 02:05:08 Rafaël Carré, vous avez écrit :
> > > vlc | branch: master | Rafaël Carré <funman at videolan.org> | Sat Nov  5
> > > 20:04:15 2011 -0400| [ebac954fe8d642adc49c4b237f3ef322b4eeb818] |
> > > committer: Rafaël Carré
> > > 
> > > win64 packaging: distribute libstdc++-6.dll and libgcc_s_sjlj-1.dll
> > 
> > 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
> 
> > 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.

> 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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis