Bug 56710

These warnings are also seen with the autotool build if you ./configure with --disable-asm (or build for a target where that is the default)

(In reply to comment #1)
> These warnings are also seen with the autotool build if you ./configure with
> --disable-asm (or build for a target where that is the default)

... and since the autotool build uses -Werror=missing-prototypes, these warnings are fatal.

See also commits 8f3be339 (which fixed a similar issue once already), and 3ed8d42 (which reverted the fix to fix it somewhere else [1])

[1] http://lists.freedesktop.org/archives/mesa-dev/2012-July/023899.html

Created attachment 70672 [details] [review]
kludge

Attached is a kludgy patch which jumps through the necessary hoops to include the GLES2 prototypes to fix these warnings, but I don't think this is the right way to fix this.

Kristian, 

This still seems to be a problem.

I can reproduce here too.

These are the current errors I see.....

In file included from glapi_dispatch.c:90:
../../../src/mapi/glapi/glapitemp.h:1640: error: no previous prototype for 'glReadBufferNV'
../../../src/mapi/glapi/glapitemp.h:4198: error: no previous prototype for 'glDrawBuffersNV'
../../../src/mapi/glapi/glapitemp.h:6377: error: no previous prototype for 'glFlushMappedBufferRangeEXT'
../../../src/mapi/glapi/glapitemp.h:6389: error: no previous prototype for 'glMapBufferRangeEXT'
../../../src/mapi/glapi/glapitemp.h:6401: error: no previous prototype for 'glBindVertexArrayOES'
../../../src/mapi/glapi/glapitemp.h:6413: error: no previous prototype for 'glDeleteVertexArraysOES'
../../../src/mapi/glapi/glapitemp.h:6433: error: no previous prototype for 'glGenVertexArraysOES'
../../../src/mapi/glapi/glapitemp.h:6445: error: no previous prototype for 'glIsVertexArrayOES'
../../../src/mapi/glapi/glapitemp.h: In function 'glMultiDrawElements':
../../../src/mapi/glapi/glapitemp.h:7541: warning: passing argument 4 of '(__builtin_expect(_glapi_Dispatch != 0u, 1l) != 0l ? _glapi_Dispatch : _glapi_get_dispatch())->MultiDrawElementsEXT' discards qualifiers from pointer target type
../../../src/mapi/glapi/glapitemp.h:7541: note: expected 'const GLvoid **' but argument is of type 'const GLvoid * const*'

mesa: 6acef6c5f779ed0ba390f556479c428a36d70edb (master)

This bug is still present and blocks autotools builds with disable-asm.

(In reply to comment #6)
> mesa: 6acef6c5f779ed0ba390f556479c428a36d70edb (master)
> 
> This bug is still present and blocks autotools builds with disable-asm.

What parameters are you passing to ./configure (or equivalently, autogen.sh)?

This is what I'm using, and I can build without problems:

./autogen.sh \
    --with-gallium-drivers= \
    --enable-gles1 \
    --disable-glut \
    --disable-asm \
    --enable-debug \
    --enable-egl \
    --enable-gles2 \
    --enable-texture-float \
    --enable-shared-glapi \
    --enable-glx-tls \
    "--prefix=$PLATFORM_INSTALL_DIR" \
    --with-dri-drivers=swrast,i915,i965 \
    CFLAGS="-O0 $CFLAGS" \
    CXXFLAGS="-O0 $CXXFLAGS"

(In reply to comment #7)
> 
> What parameters are you passing to ./configure (or equivalently, autogen.sh)?
> 

I can reproduce the build error with this configuration.

./autogen.sh --with-gallium-drivers=swrast --disable-dri --disable-asm

Created attachment 73024 [details] [review]
patch

3 of the other 4 inclusions of glapi/glapitemp.h 

(i.e., these:
src/mesa/drivers/x11/glxapi.c
src/mesa/drivers/osmesa/osmesa.c
src/gallium/targets/libgl-xlib/xlib.c
)

include it in a 

#ifdef GLX_INDIRECT_RENDERING

...

#define _GLAPI_SKIP_NORMAL_ENTRY_POINTS
#include "glapi/glapitemp.h"

#endif /* GLX_INDIRECT_RENDERING */

pattern.

src/mapi/glapi/glapi_nop.c does not, but I guess a nop implementation is allowed to be different.

src/mapi/glapi/glapi_dispatch.c does this

#if !(defined(USE_X86_ASM) || defined(USE_X86_64_ASM) || defined(USE_SPARC_ASM))

...

#ifdef GLX_INDIRECT_RENDERING
/* those link to libglapi.a should provide the entry points */
#define _GLAPI_SKIP_PROTO_ENTRY_POINTS
#endif
#include "glapi/glapitemp.h"

#endif /* USE_X86_ASM */

I have no idea about this code or this patch, but the patch makes glapi_dispatch.c match the inclusion pattern of the other files.

I've build tested it with

--with-gallium-drivers= --disable-dri --disable-asm;

--with-gallium-drivers= --disable-dri --disable-asm --enable-osmesa --disable-driglx-direct --enable-xlib-glx;

--with-gallium-drivers= --disable-asm --with-dri-drivers=

Patch sent to mailing list.

(In reply to comment #10)
> Patch sent to mailing list.

It's been pointed out to me that

_GLAPI_SKIP_NORMAL_ENTRY_POINTS and
_GLAPI_SKIP_PROTO_ENTRY_POINTS

are different things.

Adding some insight from IRC about the correct fix:

jturney: mattst88: I don't think that warning fix patch is right
jturney: including glapitemp.h with _GLAPI_SKIP_PROTO_ENTRY_POINTS and with _GLAPI_SKIP_NORMAL_ENTRY_POINTS aren't the same
krh: mattst88: the core problem there was that both gl2ext and glext was being included in the same header file
krh: and we had a hand-hacked version to gl2ext.h that didn't break when we did that
krh: but when I update to a pristine upstream gl2ext.h it broke
mattst88: jturney, krh: would someone like to send a different patch in that case? :)
jturney: Well, I have already sent a different but also wrong patch :-)
mattst88: oh, I didn't even notice that _GLAPI_SKIP_NORMAL_ENTRY_POINTS and _GLAPI_SKIP_PROTO_ENTRY_POINTS were different.
jturney: ^.^
krh: I think the right approach is to hand-code a header file with the union of entry points needed in the file that tries to include both ext.h file
krh: but it's been a while since I looked at it
krh: but more fundamentally, there's a problem with trying to include both glext.h and gl2ext.h headers, and that's probably what should be addressed

Could you still reproduce this bug?
It should be fixed/worked around with this commit:

http://cgit.freedesktop.org/mesa/mesa/commit/?id=5ea43e65498505fc5d11d63668cda165146eb55b

(In reply to comment #13)
> Could you still reproduce this bug?

Appears to be fixed to me.

(In reply to comment #14)
> (In reply to comment #13)
> > Could you still reproduce this bug?
> 
> Appears to be fixed to me.

Thanks for testing.