Bug 57379

Reproducible with git HEAD, trying to bisect.

Created attachment 77515 [details]
patch

Cannot bisect, but looks like this issue was fixed/papered over by 
http://cgit.freedesktop.org/cairo/commit/?id=465319ce828f922edce46b6e7628da543b20d5e4
and 
http://cgit.freedesktop.org/cairo/commit/?id=188c34b40d6f08851b4076ad11aefe69d4a78a25
reverted that.

Attached patch fixes the issue (but there is also makefile/libtool one: gl-related object files are pulled twice during linking).

But I don't understand why not rewrite _get_depth_stencil_format to just

static GLenum
_get_depth_stencil_format (cairo_gl_context_t *ctx)
{
    /* This is necessary to properly handle the situation where both
       OpenGL and OpenGLES are active and returning a sane default. */
#if CAIRO_HAS_GL_SURFACE
	return GL_DEPTH_STENCIL;
#endif

#if CAIRO_HAS_GLESV2_SURFACE
	return GL_DEPTH24_STENCIL8;
#endif
}

Thanks ojab! For the archives, prior to applying ojab's patch, here's the build error, assuming -devel packages (or manually built) mesa GL and GLES:

  $ ./configure --prefix={myprefix} --enable-xcb --enable-pdf \
                --disable-gtk-doc --enable-gl --enable-glesv2

  $ make

  CC     cairo-gl-device.lo
cairo-gl-device.c: In function '_get_depth_stencil_format':
cairo-gl-device.c:352:9: error: 'GL_DEPTH24_STENCIL8_OES' undeclared (first use in this function)
cairo-gl-device.c:352:9: note: each undeclared identifier is reported only once for each function it appears in

PS, cairo head is:
  http://cgit.freedesktop.org/cairo/commit/?id=a64ce09715162c57d6e4b6a460d426af1d443cdc

Ojab -- alas, attached patch breaks my build for a host of (previously masked, in all likelihood) multiple definition issues. In case it's helpful, attaching my (non-verbose) make output.

Created attachment 77889 [details]
make output after applying ojab's patch

I confirm this bug is still valid on amd64, gl and gles2 enabled.

/bin/sh ../libtool  --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I..  -I. -D_REENTRANT      -I/usr/include/pixman-1      -I/usr/include/freetype2    -I/usr/include/libdrm   -I/usr/include/libdrm  -I/usr/include/libpng16        -Wall -Wextra -Wold-style-definition -Wdeclaration-after-statement -Wmissing-declarations -Werror-implicit-function-declaration -Wnested-externs -Wpointer-arith -Wwrite-strings -Wsign-compare -Wstrict-prototypes -Wmissing-prototypes -Wpacked -Wswitch-enum -Wmissing-format-attribute -Wbad-function-cast -Wvolatile-register-var -Wstrict-aliasing=2 -Winit-self -Wunsafe-loop-optimizations -Wno-missing-field-initializers -Wno-unused-parameter -Wno-attributes -Wno-long-long -Winline -flto -fno-strict-aliasing -fno-common -Wno-unused-but-set-variable                              -O2 -pipe -O3 -march=native -pipe -finline-limit=1200 -c -o cairo-gl-dispatch.lo cairo-gl-dispatch.c
cairo-gl-device.c: In function ‘_get_depth_stencil_format’:
cairo-gl-device.c:352:9: error: ‘GL_DEPTH24_STENCIL8_OES’ undeclared (first use in this function)
  return GL_DEPTH24_STENCIL8_OES;
         ^
cairo-gl-device.c:352:9: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [cairo-gl-device.lo] Error 1

(In reply to comment #3)
> Thanks ojab! For the archives, prior to applying ojab's patch, here's the
> build error, assuming -devel packages (or manually built) mesa GL and GLES:
> 
>   $ ./configure --prefix={myprefix} --enable-xcb --enable-pdf \
>                 --disable-gtk-doc --enable-gl --enable-glesv2
> 
>   $ make
> 
>   CC     cairo-gl-device.lo
> cairo-gl-device.c: In function '_get_depth_stencil_format':
> cairo-gl-device.c:352:9: error: 'GL_DEPTH24_STENCIL8_OES' undeclared (first
> use in this function)
> cairo-gl-device.c:352:9: note: each undeclared identifier is reported only
> once for each function it appears in
> 
> PS, cairo head is:
>  
> http://cgit.freedesktop.org/cairo/commit/
> ?id=a64ce09715162c57d6e4b6a460d426af1d443cdc

*If* the only problem is the missing define, the usual way to work around this is to add something like the following to the source (or a common header):

#ifndef GL_DEPTH24_STENCIL8_OES
#define GL_DEPTH24_STENCIL8_OES GL_DEPTH24_STENCIL8
#endif

This may only fix the compile-time issue, however.

can someone tell, what is actual status?

On current git master, with --enable-gl, --enable-glx and --enable-glesv2, I get the error mentioned in the original bug description.

With the patch applied from comment #2, I get a different set of build errors:

  CCLD   libcairo.la
.libs/cairo-gl-composite.o: In function `_cairo_gl_composite_set_source':
/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:61: multiple definition of `_cairo_gl_composite_set_source'
.libs/cairo-gl-composite.o:/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:61: first defined here
.libs/cairo-gl-composite.o: In function `_cairo_gl_composite_set_source_operand':
/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:70: multiple definition of `_cairo_gl_composite_set_source_operand'
.libs/cairo-gl-composite.o:/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:70: first defined here
.libs/cairo-gl-composite.o: In function `_cairo_gl_composite_set_solid_source':
/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:78: multiple definition of `_cairo_gl_composite_set_solid_source'
.libs/cairo-gl-composite.o:/srv/Source/Cairo/cairo/build-mercia/src/../../src/cairo-gl-composite.c:78: first defined here
.libs/cairo-gl-composite.o: In function `_cairo_gl_composite_set_mask':
 etc.

Removing --enable-glx from the build options seems to result in a functional build.

As mentioned by Bryce in comment #9, if we enable --enable-gl --enable-glesv2 we get the error mentioned by Joe. 
And if we apply the patch applied from comment #2, we get multiple definitions problem. 

I feel its because of this. 
In src/cairo-gl.h file, some of the apis are declared within CAIRO_HAS_GLX_FUNCTIONS and some others within CAIRO_HAS_EGL_FUNCTIONS conditional macros, for glx and egl respectively. But other apis declarations like cairo_gl_surface_create() etc. are defined within CAIRO_HAS_GL_SURFACE || CAIRO_HAS_GLESV2_SURFACE. As per this, these apis are coming for both gl (--enable-gl) and for glesv2 (--enable-glesv2) so the reason for multiple definitions problem. 
But this also sounds good. Because these generic apis should be available for both gl and glesv2 configurations. 

So, to avoid such a condition, I feel it would be good if we use either, 
--enable-gl --enable-glx (for gl ) OR --enable-egl --enable-glesv2 (for glesv2).

As mentioned by Bryce in comment #9, if we enable --enable-gl --enable-glesv2 we get the error mentioned by Joe. 
And if we apply the patch applied from comment #2, we get multiple definitions problem. 

I feel its because of this. 
In src/cairo-gl.h file, some of the apis are declared within CAIRO_HAS_GLX_FUNCTIONS and some others within CAIRO_HAS_EGL_FUNCTIONS conditional macros, for glx and egl respectively. But other apis declarations like cairo_gl_surface_create() etc. are defined within CAIRO_HAS_GL_SURFACE || CAIRO_HAS_GLESV2_SURFACE. As per this, these apis are coming for both gl (--enable-gl) and for glesv2 (--enable-glesv2) so the reason for multiple definitions problem. 
But this also sounds good. Because these generic apis should be available for both gl and glesv2 configurations. 

So, to avoid such a condition, I feel it would be good if we use either, 
--enable-gl --enable-glx (for gl ) OR --enable-egl --enable-glesv2 (for glesv2).

Agreed.  So, sounds like the configure logic should be changed to make --enable-gl and --enable-gles* exclusive, and ditto for --enable-egl and --enable-glx.

Btw. have you noticed that both openGL and GLESv2 libraries may provide some of the same named symbols?

This might not be a problem with unified implementations like Mesa, but proprietary driver stacks might crash if you call a function from the wrong library.

I don't really know, but I would be very very careful to not mix them.

My point is, make absolutely sure by whatever means necessary, that a process does *not* link to both libGL.so and libGLESv2.so at the same time. I've had my share of problems with that, might have even been with Mesa.

Note, if there is a problem, it will not explode at compile time. It might only explode when a call is made to the wrong library at runtime.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/130.