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

[Rafaël Carré]

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

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

ok

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

http://msdn.microsoft.com/en-us/library/windows/desktop/hh310513(v=vs.85).aspx

-- 
Rafaël Carré