On OS X, GLhandleARB is void *, which is of different size than GLuint
on 64-bit. Because of this, the implementation of
glGetAttachedObjectsARB must be different from glGetAttachedShaders,
since the pointers/ints are packed the output memory.
These tell the linker to generate GNU_IFUNC relocs that rewrite the
PLT entries in the user's address space to point to our resolved GL
function, so there's no extra function pointer. It also, as a bonus,
cuts 400k out of the library.
This requires a toolchain from 2010 or so. Unfortunately, it's going
to take a bit more investigation to find out what specific bits are
required.
Fixes#4
We now initialize our dispatch table with function pointers that go
and do the rewrite, then we never have to check for a NULL table entry
again. On my 64-bit build, epoxy_glClear() drops from 83 bytes to 14,
while the total library size only goes up by 5%.
This also paves the way for fixing our dispatch table management using
TLS on windows.
This is going to change for macos and win32, and this will be easier
than trying to spread that logic through the python code and into the
generated code.
The story about how we came to needing GetProcAddress functions isn't
that interesting, but the featureset is something that should be
(particularly when comparing to similar tools that exist).
Fixes#7
Previously, these lines were using '>' which is the Markdown syntax
for a "blockquote", but within this, the '#' in "#include" was still
interpreted as a header, (which was not desired), and throwing away
the rest of the line.
It seems that a "codeblock" is what is wanted here instead, (which
should result in un-interpreted text wrapped in <pre>). Markdown
expects 4-space indent for this.
See:
https://help.github.com/articles/github-flavored-markdown
The dlopen bits are left in place, but the functions required the
types, and in the case of EGL, the types require that the platform
header actually exists.
Note that the generated code is still generated, they just aren't
built and installed. The goal with that is that someone could take
the built .c and .h files and drop it into their own project, if they
want to avoid shared libs.
From Mesa:
/* The "Interactions with APPLE_vertex_array_object" section of the
* GL_ARB_vertex_array_object spec says:
*
* "The first bind call, either BindVertexArray or
* BindVertexArrayAPPLE, determines the semantic of the object."
*/
I think we don't want to be checking that the context is actually of
the declared types -- if the extension is exposed in the extension
string, the entrypoints had better be there.
Eric Anholt
Carl Worth