After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759679 - gl: unused function '_get_plane_width'
gl: unused function '_get_plane_width'
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other FreeBSD
: Normal blocker
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-19 22:27 UTC by Koop Mast (kwm)
Modified: 2016-01-06 05:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Koop Mast (kwm) 2015-12-19 22:27:08 UTC
While building gst-plugins-bad on FreeBSD with clang 3.4.1, the following error happend.

gmake[5]: Leaving directory '/usr/home/gst/gst/head/gst-plugins-bad/gst-libs/gst/gl/egl'
gmake[5]: Entering directory '/usr/home/gst/gst/head/gst-plugins-bad/gst-libs/gst/gl'
  CC       libgstgl_1.0_la-gstgldisplay.lo
  CC       libgstgl_1.0_la-gstglcontext.lo
  CC       libgstgl_1.0_la-gstgldebug.lo
  CC       libgstgl_1.0_la-gstglbasememory.lo
  CC       libgstgl_1.0_la-gstglbuffer.lo
  CC       libgstgl_1.0_la-gstglmemory.lo
  CC       libgstgl_1.0_la-gstglmemorypbo.lo
gstglmemorypbo.c:123:1: error: unused function '_get_plane_width' [-Werror,-Wunused-function]
_get_plane_width (GstVideoInfo * info, guint plane)
^
1 error generated.
Makefile:1154: recipe for target 'libgstgl_1.0_la-gstglmemorypbo.lo' failed
gmake[5]: *** [libgstgl_1.0_la-gstglmemorypbo.lo] Error 1
gmake[5]: Leaving directory '/usr/home/gst/gst/head/gst-plugins-bad/gst-libs/gst/gl'
Makefile:1383: recipe for target 'all-recursive' failed
Comment 1 Sebastian Dröge (slomo) 2015-12-21 09:38:37 UTC
I wonder why gcc 5.3 does not complain about that. Probably because of the inline.


Matthew, is it intentionally not used currently? I see that tex_width is used together with the height variant of that function. Should that be changed over to the macro+inline function? Or should those be changed over to return tex_width maybe?
Comment 2 Sebastian Dröge (slomo) 2015-12-23 08:53:15 UTC
commit c4e5423f3b6cc346dd14f52f6a982e17cf932d12
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Dec 23 09:50:13 2015 +0100

    glmemorypbo: Comment out unused functions to fix compilation with clang
    
    It's not clear if these are intentionally unused or the code should be
    changed, but this fixes compilation for the time being at least.
    
    See https://bugzilla.gnome.org/show_bug.cgi?id=759679
Comment 3 Matthew Waters (ystreet00) 2015-12-28 07:46:38 UTC
So the difference between tex_width and GL_MEM_WIDTH() is to do with data transfers.  The only case where the two values are different is when running on gles2 and (with a non power of two stride or when stride - width * n_components is > 8).  The associated texture_scaling[2] transforms between the two values.

GL_MEM_WIDTH() is the width that is viewable in the texture.
tex_width is the actual width of the texture.

So for glmemorypbo as all the occurrences of width are only dealing with the width for data transfer, GL_MEM_WIDTH() is not needed.

Even in glmemory, GL_MEM_WIDTH() is only used to initialize tex_width.
Comment 4 Sebastian Dröge (slomo) 2015-12-28 11:51:07 UTC
So should we remove it or redefine it to just use tex_width here? The code using GL_MEM_HEIGHT() and not GL_MEM_WIDTH() looks a bit weird to me :)
Comment 5 Sebastian Dröge (slomo) 2016-01-05 08:49:05 UTC
Matthew?
Comment 6 Matthew Waters (ystreet00) 2016-01-06 05:51:57 UTC
commit 8d34c918551964d4f9d98b9c1af03bc00286f3f7
Author: Matthew Waters <matthew@centricular.com>
Date:   Wed Jan 6 15:44:52 2016 +1100

    glmemorypbo: remove unused code
    
    https://bugzilla.gnome.org/show_bug.cgi?id=759679