libGL/libOpenGL list of exported symbols

[evelikov]

Looking at the diff between mesa and GLVND libGL it seems that the latter has grown a lot extra symbols.

Thus I'm wondering if we shouldn't freeze the list of statically exported symbols. After all the OpenGL ABI clearly says "use glXGetProcAddressARB()". Obviously due to applications that already link against those symbols we cannot hide them. Then again choosing the lowest common denominator across mesa/nvidia/amd drivers seems like a good idea, imho.

To prevent symbols creeping in (due to typo in the .xml or other mistake) we could have a list of the symbols explicitly hard coded in a test - something like mesa/src/mapi/es2api/ABI-check.

-Emil

[kbrenneman]

According to the spec, libGL.so is only supposed to export OpenGL 1.2 and GL_ARB_multitexture, and apps are supposed to get at everything else with glXGetProcAddress.

Unfortunately, different implementations of libGL.so over the years have exported a much larger set, and there are a lot of broken applications out there that depend on that.

That's why libglvnd's version of libGL.so exports everything. It's at least the union of every existing implementation. Existing buggy applications will continue to work under libglvnd.

As for freezing the list, it's effectively already frozen because libglvnd uses a local copy of the XML files. Generating and checking in a hard-coded list of export symbols might be a good idea at some point, but it'll only really be necessary if and when we check in an updated copy of the XML files.

Also, if we do check in an export list, then instead of testing against it, we might as well just use it with the linker, or to replace the symbol selection logic in the current scripts.

[evelikov]

That's why libglvnd's version of libGL.so exports everything. It's at least the union of every existing implementation. Existing buggy applications will continue to work under libglvnd.

So I'm leaning towards the smallest common set, whereas you're thinking about the opposite - largest one. I'd suspect that some caution might be justified, although it does feel excessive. Esp. since some symbols (glHamSandwitch anyone) might not be available on either vendor library.

Also, if we do check in an export list, then instead of testing against it, we might as well just use it with the linker, or to replace the symbol selection logic in the current scripts.

That was "the other" thing I was thinking about :-)

[kbrenneman]

Picking a small common subset actually did break things when testing. And after the free-for-all that libGL.so's export list has been for the last 15 years, there's no way to know what symbols we actually need to avoid breaking anything.

Conversely, exporting more symbols than necessary doesn't do any harm. Any well-behaved application will simply ignore them.

[evelikov]

Seems that we have different expectations of well-behaved application (just joking). Out of curiosity what was the problematic function/application ?

Thank you very much for the discussion - I believe you concluded it perfectly. Feel free to close the issue/ticket.

[kbrenneman]

I don't remember which ones specifically, but we ran into a few of them. But, it was enough to conclude that a limited export list would cause users a lot of undue grief.