GNOME Bugzilla – Bug 474371
Can't build libsgtcontroller with VS6
Last modified: 2007-09-13 09:27:39 UTC
Hello, There are some implicit cast from guint64 to gdouble in gstinterpolation macros. VS6 doesn't support it and need the use of gst_guint64_to_gdouble. I'm adding a patch including explicit functions for uint64 cases. Let me know if you have any better idea... Seb
Created attachment 95090 [details] [review] gstinterpolation.c patch
Looks good IMHO... GstLFOControlSource works with VS6?
...or maybe give the DEFINE_* macros a new parameter which is for uint64 the gst_guint64_to_gdouble() and for everything else an empty macros like #define EMPTY(x) (x) That would at least prevent the code duplication in your patch... what do you think?
Good idea, I'll do that and commit. Thanks
Sebastien, does GstLFOControlSource from latest CVS build with VS6? There is probably exactly the same problem (casting guint64 to doubles).
I didn't get error but may be I didn't build it yet. As I'm building with VS6 I have to add new files to the project manually. I'll check and use the empty macro depending on types as well.
Created attachment 95220 [details] [review] gstcontroller patch Ok, I've applied all changes needed to build with VS6 using the method you suggested. Could you review this patch please ? It builds on VS6 but I don't really know how to test that. can you try to build it with gcc and run unit tests if they exist. Thank you, Sebastien
There are still some gst_util_guint64_to_gdouble() in there instead of convert(), otherwise looks good. I'll test it when you updated the patch but should be fine :)
Yes there are still some gst_util_guint64_to_gdouble because they are needed in all cases. They are used on variables that are declared without using ##type. If you have seen one which is used on variable defined using the dynamic type let me know. (I've just rechecked ...)
Oh, you're right... sorry. I should've thought about it a bit more :) Looks good but the unit test fails with your patch: libs/controller.c:1677:F:general:controller_lfo_saw:0: Assertion 'GST_TEST_MONO_SOURCE (elem)->val_ulong == 200' failed libs/controller.c:1748:F:general:controller_lfo_rsaw:0: Assertion 'GST_TEST_MONO_SOURCE (elem)->val_ulong == 0' failed libs/controller.c:1823:F:general:controller_lfo_triangle:0: Assertion 'GST_TEST_MONO_SOURCE (elem)->val_ulong == 100' failed Any idea? :)
Ok, found the bug... you called gst_guint64_to_gdouble() on a substraction that could be negative. I changed it to call it on the two parts and do the substraction on the doubles. 2007-09-13 Sebastian Dröge <slomo@circular-chaos.org> Patch by: Sebastien Moutte <sebastien at moutte dot net> * libs/gst/controller/gstinterpolation.c: * libs/gst/controller/gstlfocontrolsource.c: Use gst_guint64_to_gdouble() when converting from a uint64 or GstClockTime to double to fix the build on win32. Fixes #474371.
Great ! I hadn't the time to search this week. Thanks :)