Libepoxy currently depends on all headers living under the same prefix.
This is not necessarily true: X11 headers can live in a separate prefix,
for instance under /opt/X11. This is also the case when cross-compiling to
a platform that sets up the build environment in non-standard ways.
We could add `x11_dep` and `egl_dep` to the libepoxy target dependencies,
but that could potentially add spurious linker flags and cause libepoxy to
depend on libraries it will dlopen() during normal operations.
To avoid that case, we use a partial_dep() object from Meson, and we limit
the dependency to compiler flags and inclusion paths.
This maintains compatibility with previous behavior of
always using GLX_LIB if it is found. The only change is
when there is no GLX_LIB.
Previous behavior when no GLX_LIB:
- abort.
New behavior when no GLX_LIB:
- Try to load libOpenGL.so as gl_handle (glx_handle remains NULL).
- Else, abort.
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Since we're generating stub types from khrplatform.h because we can't
include it reliably, we'll have to deal with some of the fallout of the
Win64 types.
Fixes: #246
GTK currently fails to detect if epoxy has been built with EGL on
Windows when epoxy is a subproject. To fix that it needs to get that
information from the dependency variables.
This requires Meson >=0.54.0 for setting variables in
declare_dependency().
Without additional check, even if libOpenGL was loaded, libGL.so will
be loaded as well, and used both in gl_handle and glx_handle, so
libglvnd libraries will not be used.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Throughout the mesa project we've been using 100 for GLES2's shading
language. It was pretty clearly the intent here, but the clever
inline detection of "am I parsing a GLSL version or a GL version
string" forgot about GLSL 1.0.x, and thus returned 10.
Saves 7k of text from the binary. You can already tell what kind of
extension it is from the prefix on the extension name anyway.
1121212 56800 160 1178172 11fa3c master.so
1114236 56800 160 1171196 11defc providernames.so
When building on macOS we don't have access to EGL, and GLX support is
conditional.
We should ensure we're using the appropriate paths depending on the
platform, and protect our use of macros to avoid undefined symbols.
Closes: #176
Our caller may load (eg) epoxy_glAlphaFunc, which is a function pointer,
and then call through that value multiple times. Until the caller
re-examines the value of that function pointer, which is a copy
relocation in the executable, repeated calls mean repeated work
resolving the GL function.
We can't make the caller reinspect the variable, but the resolver
function can avoid doing redundant work.
Fixes: anholt/libepoxy#171
Signed-off-by: Adam Jackson <ajax@redhat.com>
Epoxy updates the function pointers in order to avoid calling the
resolver multiple times, but with -Bsymbolic we're going to update the
copy inside libepoxy, instead of the relocated copy in the code using
libepoxy. This leads to libepoxy constantly querying the function
resolver code instead of just once.
We still want to avoid intra-library relocations for our functions,
but we need to live with them for our global function pointers.
See issue #171
We want to consistently handle exceptions for the internal state checks;
calling `exit()` does not allow us to attach a debugger and get a proper
trace.
Now that we're being conservative about probing libraries, these
entrypoints would not succeed unless the caller had already dlopened
stuff themselves, or had explicitly linked against the provider library.
Both of those are exactly not what we want.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Mostly this is to get all the calls to get_dlopen_handle nicely isolated
so they're easier to reason about.
Signed-off-by: Adam Jackson <ajax@redhat.com>
dlsym(NULL) can only see (symbols in) libraries that are loaded
RTLD_GLOBAL, but our dlopen()s are RTLD_LOCAL and probably so was the
one the app did if it did one. So use RTLD_NOLOAD to probe for the
library even if it's LOCAL, iff the lookup is non-fatal.
Having done that, don't ever load any libraries on this path. We only
perform this check while resolving rendering API functions, and the
window system resolution paths already load the appropriate library if
they need to. Since you have to have gone through a winsys to get a
context, and our resolvers only run when a function is _called_, this
would only introduce a failure mode if you tried to call a function
without a context bound.
Signed-off-by: Adam Jackson <ajax@redhat.com>
We're about to change our dlopen paths to do RTLD_NOLOAD more
aggressively. The issue then is we can create an EGL GLES context
without libGLES* ever being loaded. test/egl_gles2_without_glx will fail
in such a world: the first gentle probe for libGLESv2 will fail, then
the less-gentle probe for libGLESv1_CM will be shot down by the test,
and we exit.
Fortunately by the time we've gotten to this point the context exists,
so we can query its version via EGL instead.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Meson 0.46 introduced a function to check for linker flags passed to the
compiler; since the version is really brand new, I don't want to bump
the dependency on Meson just yet, so we're going to conditionally use
get_supported_link_arguments() only if we're building with Meson 0.46 or
later.
As per the previous commit, instead of assuming that Apple doesn't have dlvsym
but everywhere else does, actually check for dlvsym() existing as that function
is glibc-specific.
Even though meson will find the dependency gl on macOS, this does not mean that
there is a pkg-config file for it, as meson does not use pkg-config to
establish its presence. It should therefore not be added to
the libepoxy pkg-config file as a (private) requirement.
The GL version minor numbers haven't hit 10, yet, but if they do we're
going to get non-sensical encoded versions when calling
epoxy_gl_version(), like we're getting right now, with the GLSL version
numbers.
If the minor number is larger than the multiplication factor used for
the major number, we should bump up the factor to the next order of
magnitude.
When building on Android we end up in the Linux branch of the symbol
loading logic, but the __ANDROID__ conditional does not have the
OPENGL_LIB symbol defined, and that breaks the build.
Closes: #152
Epoxy should provide a function that returns the version of the GL
shading language in use, in the same vein as it allows to get the
version of GL.
Closes: #145
Epoxy can be compiled with GLX and X11 native resources on EGL. We can
disable the former, but the latter is always built in when enabling EGL
support.
Some platforms do not support X11 at all, so we need a way to disable
X11 when configuring Epoxy.
If the system we're building Epoxy on has GL and EGL pkg-config modules,
then we should add them to the Requires.private field of the pkg-config
file.
The Requires.private field does not contribute to the linker flags
generated by pkg-config, unless we're doing a static build; it does,
however, contribute to the compiler flags generated by pkg-config, which
means that platforms that specify ad hoc compiler flags for their GL and
EGL implementations via pkg-config will be able to propagate them
through Epoxy.
Closes: #139
Instead of using a template file, and filling in the blanks, we can use
the Meson pkgconfig module to generate the pkg-config file mostly from
the library object itself — including dependencies and flags.
The template file remains in tree for the Autotools build.
Both gcc and clang define __ANDROID__ but not ANDROID when targeting Android so
at least with the Meson build, and an NDK r16 toolchain, testing on
Android failed without this change.
This avoids any unnecessary allocations when simply passing static strings
to be printed onto stderr, and uses the simpler fputs mechanism.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>