Bug 75098 - OpenGL ES2 with fbdev - link error
Summary: OpenGL ES2 with fbdev - link error
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: EGL (show other bugs)
Version: 10.0
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-17 14:55 UTC by Christian Prochaska
Modified: 2014-02-21 22:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
mapi/es2api: unconditionaly link against glapi/glapi.la (927 bytes, patch)
2014-02-17 15:33 UTC, Emil Velikov
Details | Splinter Review
configure: use shared-glapi when more than one gl* API is used (1.72 KB, patch)
2014-02-19 00:55 UTC, Emil Velikov
Details | Splinter Review

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.