[vlc-devel] Mingw32 build problems: Dash, Skins2 and libstdc++

[Rafaël Carré]

Le 2012-06-26 19:20, Chris Smowton a écrit :
> On 26/06/2012 17:33, Chris Smowton wrote:
>> On 26/06/2012 08:44, Rafaël Carré wrote:
>>> Try to build gcc with --disable-shared
>> So I hacked around the previous problem by manually running libtool 
>> with -static, which worked. However I found that the package produced 
>> at the end of the day had a lot of broken modules, mostly because they 
>> included dependencies on libstdc++-6.dll and some libgcc DLLs.
>>
>> I'll try a rebuilding mingw64 with --disable-shared as you suggest. 
>> Since it appears to be the default for mingw64 trunk to use a shared 
>> runtime where possible, and the VLC packaging mechanism seems to make 
>> no attempt to distribute the MinGW C/C++ runtime, should the page 
>> http://wiki.videolan.org/Win32Compile mention that restriction?
> I can confirm the GCC build option fixed matters. It seems that switch 
> is sparsely documented, least of all by the GCC team themselves, but it 
> appears to do what I'd hope, i.e. statically link the CRT (and 
> libstdc++) into built programs whilst continuing to permit them to 
> depend dynamically on libvlc.dll, Windows core DLLs and so on.
> 
> One problem remains: after that rebuild, almost all modules work except for:
> 
> [0055b428] main libvlc warning: cannot load module `c:\Program Files 
> (x86)\VideoLan\VLC-git\plugins\gui\libqt4_plugin.dll' (Invalid access to 
> memory location. (error 998))
> [0055b428] main libvlc warning: cannot load module `c:\Program Files 
> (x86)\VideoLan\VLC-git\plugins\meta_engine\libtaglib_plugin.dll' 
> (Invalid access to memory location. (error 998))
> [0055b428] main libvlc warning: cannot load module `c:\Program Files 
> (x86)\VideoLan\VLC-git\plugins\visualization\libprojectm_plugin.dll' 
> (Invalid access to memory location. (error 998))
> 
> Dependency Walker doesn't suggest those plugins have anything 
> particularly wrong with them. Fortunately I don't care about the QT GUI, 
> but do you have any idea why this might happen? Debugging the error is 
> tricky when my build machine and target machine are so far removed!

Try gcc 4.6, at least the debian version from experimental works fine.

Note, all these modules are in C++