https://bugs.freedesktop.org/show_bug.cgi?id=35560
Summary: libOSMesa.so now (since 7.2 perhaps) contains the GL
API preventing creating one executable with
interchangeable libGL.so files
Product: Mesa
Version: 7.10
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: Mesa core
AssignedTo: [email protected]
ReportedBy: [email protected]
With Mesa 7.2 we used to build a single application and link against libGL.so
and a fake OSMesa library that contained the same dozen or so API's that OSMesa
provided. Then at load time using LD_LIBRARY_PATH, rld would either pick up the
native libGL.so and our fake libOSMesa.so or libGL.so from Mesa and the real
libOSMesa.so. Now that libOSMesa.so has the all the GL API symbols resolved
within itself we can no longer do this. We are then forced to create two
different executables. One that links to native libGL.so and the other that
links to libOSMesa.so. In the first case the native libGL.so can easily be
swapped out at load time by changing the LD_LIBRARY_PATH but we can not use
OSMesa's offscreen rendering. In the second case we can not do on-screen
rendering.
We do I suppose have a workaround which is to create our own GL API that either
calls the native libGL.so or the Mesa version (assuming we can decorate the
API, which I think we can).
As a quick workaround we simply removed the GL objects from the command that
creates the libOSMesa.so library. In addition to this we were forced to export
several dozen additional functions within Mesa's libGL.so for libOSMesa.so.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
