[Mesa-dev] [Bug 30172] GL_EXT_framebuffer_blit function required
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Thu Sep 16 22:46:17 PDT 2010
https://bugs.freedesktop.org/show_bug.cgi?id=30172
--- Comment #22 from Luca Barbieri <luca.barbieri at gmail.com> 2010-09-16 22:46:17 PDT ---
> The issue with ELF weak symbols is that there can only be one of them.
> Or rather, if one is normal and one is weak, you get the normal one
> and the weak one is forgotten, but in at least my case you cannot know
> until runtime which you need.
Not sure what you mean.
What I'm proposing (mostly theoretically) is to add assembly/compiler
directives to the headers that cause application references to be weak.
If a symbol reference is weak, then it gets set to NULL if it cannot be
resolved to a symbol, rather than causing a fatal error.
Thus, you could then liberally reference functions directly, as long as you
check that the extension is supported before actually calling them.
> yes, that's back to my original point w/ exporting the bare minimum: I
> *want* to know that there's no possibility of using a function which
> might not be exported -- at build time.
This is solvable by exporting the functions from libGL.so.1, but not from
libGL.so, since "ld" reads the latter, while "ld.so" reads the former.
To do this, Mesa would need to link libGL twice with two different linker
version scripts, and ship both, instead of making libGL.so a symlink to
libGL.so.1.
It's also probably possible to strip the section bodies from such a libGL.so to
significantly reduce the size.
A developer who instead prefers to have an increased chance of compiling random
example code could just remove libGL.so and run ldconfig.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the mesa-dev
mailing list