[vlc-devel] [vlc-commits] win64 packaging: distribute libstdc++-6.dll and libgcc_s_sjlj-1.dll
remi at remlab.net
Mon Nov 7 14:21:41 CET 2011
On Sun, 6 Nov 2011 18:38:05 -0500, Rafaël Carré <funman at videolan.org>
>> > > , not to mention sljl vs dw2.
>> > mingw-w64 doesn't support dw2
>> Right, so absolutely no way a .dll with dw2 would be loaded before
> static vs shared linking doesn't change this, does it?
No. dw2 will get a different DLL file name, or will be statically linked
into the application. This means several different instances of the C++
run-time in the same process. This works fine as long as LibVLC does not
expose anything C++, in particular no C++ objects is passed from one to the
other. This has worked before, and it will continue to work. Static linking
means we get as many instances of C++ as VLC plugins using C++. In that
respect, dynamic stdc++ will save a bit of memory in VLC.
> i'll paste irc logs on #mingw-w64 about exceptions:
> 20:51 < jon_y> funman: do not statically link libgcc/libstdc++ if you
> using dlls
> 20:51 < funman> jon_y: why not?
> 20:51 < jon_y> funman: they break in unexpected ways
> 20:52 < funman> i'm making dlls (loadable plugins)
> 20:52 < jon_y> libgcc/libstdc++ may do some initializations itself
> 20:53 < jon_y> so if you use any functions from them (you would have
> them), their data especially pointer blobs must not
> be shared with anything external
> 20:53 -!- TaPiOn [b at ivr94-6-82-230-254-123.fbx.proxad.net] has quit
> timeout: 480 seconds]
> 20:53 < jon_y> also, c++ exceptions don't work at all
> 20:53 < jon_y> *when crossing dll boundaries
> 20:54 < jon_y> this static link should really be deprecated sinse it
> work properly for most users
C++ exceptions are not going to work anyway (see above) and are
fortunately not an issue.
But he has a point. If a DLL, stdc++ or other, has static initializations,
then it MUST be a DLL, due to limitations in Win32. Namely, Windows can
only deal with one DllEntry() per DLL. Thus statically linked libraries
cannot use any kind of static initializer or static constructor/destructor
>> It did work, but broke in all external applications, notably in the
>> webbrowser, who didn't find avcodec-51.dll, because it wasn't in its
To be fair, I think this should not be a problem in currently
VLC-supported Windows versions, and any such broken Windows version does
not deserve to be supported. VLC would not be the first application to ship
its DLL's in its own directory; most games have done this for years).
That being said, if someone wants to change this in VLC, (s)he better be
ready to deal with the potential support issues. This needs to be very well
tested - not just be running vlc.exe.
More information about the vlc-devel