GNOME Bugzilla – Bug 576499
build scripts use -Werror option, and build fails because of warnings
Last modified: 2009-08-10 23:41:01 UTC
Please describe the problem: gst-openmax uses the -Werror option by default, which causes the build to fail even if there are build warnings. There are several warnings that cause the build to fail, all of which fall under one of these two categories: 1) Failure to include <stdlib.h> and using calloc or free. 2) Using the incorrect printf format specifier (%lu for a guint, %d for a long int). Steps to reproduce: These are common warnings found with -Wall (which is also on by default for gst-openmax). I would expect that this problem is easily reproducable by most gcc compilers. In my case, I'm using the MontaVista Pro 5.00 compiler, which is based on gcc 4.2.0. Actual results: During a typical build, I see the errors below. No fancy configure options other than --prefix are used: gstomx_base_videodec.c:111: warning: implicit declaration of function 'calloc' gstomx_base_filter.c:387: warning: format '%d' expects type 'int', but argument 8 has type 'OMX_U32' And many more like this. Expected results: I would expect that the build does not fail. Minimally, developers shouldn't be using -Werror if there are still build warnings. Does this happen every time? Yes. Other information: I have a patch that fixes the build issue, but don't see a place to attach it on this submission screen.
Created attachment 131224 [details] [review] Proposed patch to fix build errors. With this patch, the gst-openmax build completes without failure.
Even if you can't reproduce this issue, the changes I make in the patch are really simple and it should be easy to verify that it is correct.
Don, that patch looks empty.
Can you commit your patch and then do 'git format-patch'? http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
Why not just use the glib methods ? g_malloc, g_new0, g_free, etc... That would avoid all those issues of portability (amongst other things)
(In reply to comment #5) > Why not just use the glib methods ? g_malloc, g_new0, g_free, etc... > > That would avoid all those issues of portability (amongst other things) Huh? stdlib.h is not portable? I used calloc because I wanted to make a clear distinction between what goes to GStramer and what goes to OpenMAX. Besides, there's no g_calloc.
> Besides, there's no g_calloc. That's true, it's called g_malloc0() :)
or g_new0()
Actually, this patch is for 0.10.0.4, this has been fixed in git master a lont time ago, please use that. I'll try to release 0.10.0.5 ASAP. So... already fixed.
(In reply to comment #8) > or g_new0() or use memset and avoid the alloc completely, which is precisely what I'm going to do.