When initially writing the Makefiles, I started from a Makefile.am
that had ajax's copyright instead of an Intel one. The only line I
can see that's left from the original Makefile.am is "pkgconfigdir" in
the root Makefile.am.
For a non-GLX application, at least, we need to pull our extensions
using dlsym, not glXGetProcAddress(). The symptom was a segfault in
glXGetProcAddress().
In addition to the failing testcase, there were a couple of
regressions in piglit's attribs test: one from glBegin_unwrapped vs
glBegin confusion in the __asm__ directives we were generating, and
one where the function pointers apparently were just getting mixed up
at application runtime.
For the dynamically-linked tests, it wasn't a big deal because the
updated library was always picked up. But for glx_static, we were
actually testing stale code.
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
Eric Anholt
Carl Worth