Bug 75098

Summary: OpenGL ES2 with fbdev - link error
Product: Mesa Reporter: Christian Prochaska <christian.prochaska>
Component: EGLAssignee: mesa-dev
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: 10.0   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: mapi/es2api: unconditionaly link against glapi/glapi.la
configure: use shared-glapi when more than one gl* API is used

Description Christian Prochaska 2014-02-17 14:55:48 UTC
I've built Mesa 10.0.3 for using OpenGL ES 2 on fbdev with the following configuration:

./configure --enable-gles2 --disable-dri --enable-gallium-egl --with-egl-platforms=fbdev --with-gallium-drivers=swrast

When I tried to build the 'es2gears' example (from the mesa-demos archive) using the command

gcc -o es2gears es2gears.c ../eglut/eglut_screen.c ../eglut/eglut.c -I../eglut -lGLESv2 -lEGL -lm

the following link error occured:

/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_Dispatch'
/usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
collect2: error: ld returned 1 exit status

I could finally get it to work by adding the '--enable-shared-glapi' configure option (which made libGLESv2.so link with libglapi.so.0, which contains the missing symbols), but only after editing the configure script to not make this option depend on DRI ("Shared GLAPI is only useful for DRI, disabling").

Is this the correct solution or is the real problem somewhere else?
Comment 1 Emil Velikov 2014-02-17 15:33:58 UTC
Created attachment 94216 [details] [review]
mapi/es2api: unconditionaly link against glapi/glapi.la

Hi Christian, thanks for the report.

I must admit that these are rather unusual configure flags, which are not tested too often.

* Are you able to use the libGLESv2.so library, (eg. use a precompiled es2gears)? I'm assuming that is not the case.

With that said, the attached patch should help, although I'm not sure if it's the correct solution as the api dispatch is out of my current scope :-)
Comment 2 Christian Prochaska 2014-02-17 16:45:48 UTC
Hi Emil,

(In reply to comment #1)
> Created attachment 94216 [details] [review] [review]
> mapi/es2api: unconditionaly link against glapi/glapi.la
> 
> Hi Christian, thanks for the report.
> 
> I must admit that these are rather unusual configure flags, which are not
> tested too often.
> 
> * Are you able to use the libGLESv2.so library, (eg. use a precompiled
> es2gears)? I'm assuming that is not the case.

When I build es2gears with the 'working' (shared glapi) Mesa installed and then uninstall Mesa and install the non-shared glapi Mesa version and execute the previously built es2gears binary, this error occurs:

./es2gears: symbol lookup error: /usr/local/lib/libGLESv2.so.2: undefined symbol: _glapi_Dispatch

> With that said, the attached patch should help, although I'm not sure if
> it's the correct solution as the api dispatch is out of my current scope :-)

Unfortunalely, it doesn't build:

/bin/bash ../../../libtool  --tag=CC   --mode=link gcc -fvisibility=hidden -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp  -version-number 2 -no-undefined  -o libGLESv2.la -rpath /usr/local/lib entry.lo -ldrm   -lm -lpthread -ldl ../../../src/mapi/glapi/libglapi.la  
libtool: link: gcc -shared  -fPIC -DPIC  .libs/entry.o  -Wl,--whole-archive ../../../src/mapi/glapi/.libs/libglapi.a -Wl,--no-whole-archive  -ldrm -lm -lpthread -ldl  -O2   -Wl,-soname -Wl,libGLESv2.so.2 -o .libs/libGLESv2.so.2.0.0
../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glCullFace':
/home/christian/projects/mesa/mesa/src/mapi/glapi/glapi_x86.S:305: multiple definition of `glCullFace'
.libs/entry.o:entry.c:(.text+0x0): first defined here
../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glFrontFace':
/home/christian/projects/mesa/mesa/src/mapi/glapi/glapi_x86.S:310: multiple definition of `glFrontFace'
.libs/entry.o:entry.c:(.text+0x20): first defined here
../../../src/mapi/glapi/.libs/libglapi.a(glapi_x86.o): In function `glHint':
.libs/entry.o:entry.c:(.text+0x40): first defined here
...
Comment 3 Emil Velikov 2014-02-19 00:55:19 UTC
Created attachment 94319 [details] [review]
configure: use shared-glapi when more than one gl* API is used

Hmm forcing shared-glapi whenever more than one gl* api is used seems like the only sensible thing to do imho.

This patch fixes the problem by convering the dri dependency gl*. Feel free to give the patch a try.

-Emil
Comment 4 Christian Prochaska 2014-02-19 16:22:16 UTC
(In reply to comment #3)
> Created attachment 94319 [details] [review] [review]
> configure: use shared-glapi when more than one gl* API is used
> 
> Hmm forcing shared-glapi whenever more than one gl* api is used seems like
> the only sensible thing to do imho.
> 
> This patch fixes the problem by convering the dri dependency gl*. Feel free
> to give the patch a try.


This patch works for me. Thanks.
Comment 5 Emil Velikov 2014-02-21 22:53:55 UTC
Pushed to master

commit 0432aa064bf5d4d0ad8fc3c4d648b8feb238ddfa
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Wed Feb 19 00:54:04 2014 +0000

    configure: use shared-glapi when more than one gl* API is used

    Current behaviour states that shared-glapi is usefull when building
    with dri, which is not the case. Shared-glapi is used to dispatch
    the gl* functions across the one or more gl api's which can be dri
    based but do not need to be.

    Fixed the following build

     ./configure --enable-gles2 --disable-dri --enable-gallium-egl \
          --with-egl-platforms=fbdev --with-gallium-drivers=swrast

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.