GLEW has grown support for OpenGL 3.2+ core contexts over the years.
Everything else has stayed pretty much the same, though, so you should
still use Epoxy over libGLEW.
Use the appropriate Markdown syntax (with GitHub extensions) for code
blocks and preformatted bits, and update the build instructions and
dependencies for Meson and Ninja.
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
For performance, I want to be able to make single-context (well,
single-pixel-format-and-device) apps be able to directly call GL
functions through function pointers. Bake that into the ABI now so I
can get a release out the door and fix this up later.
This also fixes the lack of __stdcall annotation on the
PFNWHATEVERPROC typedefs.
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.
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
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
Emmanuele Bassi
Nigel Stewart
Caleb Anderson
Yaron Cohen-Tal
Eric Anholt
Carl Worth