[vlc-devel] [vlc-commits] win64 packaging: distribute libstdc++-6.dll and libgcc_s_sjlj-1.dll
funman at videolan.org
Mon Nov 7 00:38:05 CET 2011
Le Sun, 6 Nov 2011 18:45:32 +0100,
Jean-Baptiste Kempf <jb at videolan.org> a écrit :
> > > , 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?
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
> > > Not to mention the different webplugins loaded in memory by a browser.
> > which different plugins?
> I don't know, any webplugin + vlc one.
> Any application loading libVLC after
> > > And of course, I expect you will do the support on the forum and mailing
> > > lists for users who don't understand what happens based on their
> > > configuration.
> > win64 builds are still in early testing phase
> We already tried dlls in VLC, see 0.9.4 win32 build, for example.
> 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
More information about the vlc-devel