Bug 78101 - [bisected] Mesa demos fails to link with drawtex.c:34: undefined reference to `glDrawTexfOES'
Summary: [bisected] Mesa demos fails to link with drawtex.c:34: undefined reference to...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Demos (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Tapani Pälli
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-30 04:56 UTC by Scott Moreau
Modified: 2014-05-12 09:41 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
hopeful patch to fix the issue (1.29 KB, patch)
2014-04-30 11:07 UTC, Tapani Pälli
Details | Splinter Review
drawtex: fixed compiler warnings related to use of eglGetProcAddress (1.04 KB, text/plain)
2014-05-09 10:38 UTC, Stefan Dirsch
Details

Description Scott Moreau 2014-04-30 04:56:43 UTC
Mesa demos fails to link with the following errors:

drawtex.o: In function `draw':
/demos/src/egl/opengles1/drawtex.c:34: undefined reference to `glDrawTexfOES'
collect2: error: ld returned 1 exit status
make[3]: *** [drawtex_screen] Error 1
make[3]: *** Waiting for unfinished jobs....
drawtex.o: In function `draw':
/demos/src/egl/opengles1/drawtex.c:34: undefined reference to `glDrawTexfOES'
collect2: error: ld returned 1 exit status
make[3]: *** [drawtex_x11] Error 1
make[3]: Leaving directory `/demos/src/egl/opengles1'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/demos/src/egl'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/demos/src'
make: *** [all-recursive] Error 1

The problem stems from mesa commit 1a59f9a131318e1239b47b9ea4fe7c84f461cf37

Author: Ian Romanick <ian.d.romanick@intel.com>
Date:   Wed Mar 26 12:57:47 2014 -0700

    mapi_abi: Make ES1 and ES2 static_dispatch=false functions hidden
    
    This has been a long standing issue with the ES libraries.  Functions
    marked in the XML with 'static_dispatch=false' were still incorrectly
    exported.  ABI-check is supposed to detect this case, but we have to
    paper over failures every time a new extension is added.
    
    This change will cause a big pile of functions to disappear from
    libGLESv2 and libGLESv1_CM.
Comment 1 Tapani Pälli 2014-04-30 10:00:50 UTC
did you run make with a clean directory (make clean or git clean -fdX)?
Comment 2 Scott Moreau 2014-04-30 10:12:47 UTC
(In reply to comment #1)
> did you run make with a clean directory (make clean or git clean -fdX)?

Yes. demos build and link with mesa dfccd5ccd73ec8e9607826c62fb6bf31f9628719 but linking fails with mesa 1a59f9a131318e1239b47b9ea4fe7c84f461cf37.
Comment 3 Tapani Pälli 2014-04-30 11:07:08 UTC
Created attachment 98234 [details] [review]
hopeful patch to fix the issue

I'm having problems configuring demos build system to reproduce this ... however for me it seems the reason for failure is that drawtex.c uses function which is not part of opengles1.1 API but an extension function which should be resolved via eglGetProcAddress instead. Attaching a hopeful fix to try.
Comment 4 Scott Moreau 2014-04-30 15:53:21 UTC
(In reply to comment #3)
> Created attachment 98234 [details] [review] [review]
> hopeful patch to fix the issue
> 
> I'm having problems configuring demos build system to reproduce this ...

No special configuration for demos is needed. As far as I can tell, mesa just needs to be built with gles1 enabled.

> however for me it seems the reason for failure is that drawtex.c uses
> function which is not part of opengles1.1 API but an extension function
> which should be resolved via eglGetProcAddress instead. Attaching a hopeful
> fix to try.

This patch allows demos to build successfully here.
Comment 5 Ian Romanick 2014-04-30 16:10:31 UTC
The demos need to use eglGetProcAddress for extension functions.  The patch is the right approach, but having a non-static function pointer with the same name as a function is very dangerous.  You wouldn't declare 'int (*printf)(const char *, ...);' in your code and expect things to work, would you? :)

This is why GLEW names the function pointers __glewFoo and has a #define glFoo that calls it.
Comment 6 Tapani Pälli 2014-04-30 16:51:31 UTC
(In reply to comment #5)
> The demos need to use eglGetProcAddress for extension functions.  The patch
> is the right approach, but having a non-static function pointer with the
> same name as a function is very dangerous.  You wouldn't declare 'int
> (*printf)(const char *, ...);' in your code and expect things to work, would
> you? :)
> 
> This is why GLEW names the function pointers __glewFoo and has a #define
> glFoo that calls it.

That is why I left OES out of the name but I can change it to something better (?)
Comment 7 Tapani Pälli 2014-05-05 05:21:29 UTC
I've send a modified patch to mesa-dev mailing list.
Comment 8 Tapani Pälli 2014-05-06 04:34:43 UTC
fix pushed to master
Comment 9 Stefan Dirsch 2014-05-09 10:38:13 UTC
Created attachment 98745 [details]
drawtex: fixed compiler warnings related to use of eglGetProcAddress

Apparently your patch resulted in some compiler warnings. The attached patch fixes them.
Comment 10 Tapani Pälli 2014-05-09 15:26:36 UTC
(In reply to comment #9)
> Created attachment 98745 [details]
> drawtex: fixed compiler warnings related to use of eglGetProcAddress
> 
> Apparently your patch resulted in some compiler warnings. The attached patch
> fixes them.

I assumed egl was already around with 'eglut' but that's not the case. Thanks for the fix, I'll test and commit it soonish.
Comment 11 Stefan Dirsch 2014-05-10 22:35:01 UTC
Wonderful. Thanks a lot!
Comment 12 Tapani Pälli 2014-05-12 09:41:45 UTC
compiler warnings patch submitted


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.