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

[Rémi Denis-Courmont]

On Sun, 6 Nov 2011 18:38:05 -0500, Rafaël Carré <funman at videolan.org>
wrote:
>> > > , 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
>> yours.
> 
> 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
are
> 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
used
> 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
[Ping
> 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
never
> 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
on Windows.

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

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.


-- 
Rémi Denis-Courmont
http://www.remlab.net/