[gst-devel] Gstreamer WIN32 status

Steve Lhomme steve.lhomme at free.fr
Mon Apr 10 01:42:05 CEST 2006

Sébastien Moutte wrote:
>>>>> It's time to report the WIN32 status of gstreamer packages. Now a 
>>>>> lot of plugins build successfully with MSVC 6.0 and the ones i have 
>>>>> tested work really good :)
>>>> Why not support MSVC2005 (instead) ? That's the only free one and 
>>>> performs much better.
>>> Yep, sure it is really better than VC6.0 or VC7.1 and I will add 
>>> project files for it too, but the problem is we can't build binaries 
>>> packages with it as it links on msvcr80.dll which is not LGPL compliant. 
>> That's the first time I hear something like that. LGPL can use closed 
>> source libraries AFAIK. It's not part of your code. And your code 
>> doesn't depend on it. Only a version of the binary does, but it's not 
>> mandatory (as in derivative work).
>>> Moreover, most of the binary packages of the gstreamer's dependencies 
>>> are distributed linked on msvcrt.dll (6.0) then peoples who will want 
>>> to work with MSVC2005 will have to build all dependencies before ...
>> I don't think so. It's not because a library you use depend on X that 
>> your library has to depend on library X instead of Y. You could build 
>> a plugin that uses msvcrt90.dll or toto.dll and still leave the rest 
>> of GStreamer, glib, etc intact.
> That's not always true ! You can't share resources across the msvcrt.dll 
> and msvcr80.dll boundary.
> http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

True, but I hope GStreamer doesn't need that (the core should be 
consistent, then the rest should be free). The only case I've 
encountered so far is when you use different memory models and share 
FILE* instances.


More information about the gstreamer-devel mailing list