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>
If you've built Mesa with --disable-texture-float, and try to run the
tests against Xvfb, glx_public_api_core will fail: creating a direct
context with llvmpipe will fail because you don't have
ARB_texture_float, and the internal fallback to an indirect context will
fail because indirect only supports through 1.4. So the server will
throw GLXBadFBConfig at you to say "I don't support core contexts",
which we should interpret as a skip not a failure.
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.
build_apple was introduced in 756dca as a proxy for the fact that Apple's libc
doesn't have dlvsym(), which is glibc-specific so also isn't present in other
libc implementations such as musl.
Instead of detecting whether we are building for Apple or not, just probe the to
see if we have dlvsym.
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.
Instead of iterating over the list of compiler flags, we should use the
get_supported_arguments() method of the compiler object, which does it
for us — and maybe, in the future, will be optimised to do the checks in
parallel.
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
The `enable-` prefix is an Autotool-ism; idiomatic naming for Meson
projects should just use the name of the option, and rely on the type
to convey meaning, especially because Meson does not have `disable`
aliases that avoid the explicit `enable-foo=no` cases.
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.
The common EGL testing code uses XOpenDisplay(), which means we need to
explicitly include the Xlib.h header file, instead of relying on
something else stringing it along.
We currently run CI on Linux only, given that the macOS builders in
Travis are always fairly overwhelmed; thus, there's no need to
complicate the Travis script with a conditional that is always going to
be true.
Add libOpenGL to the list of libraries we'll intercept. This is harmless
if glvnd is not available as the dlopen(libOpenGL.so) will fail, but
without this we can't intercept glGetString, which the
egl_and_glx_different_pointers_glx test needs to be able to do.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Adam Jackson
Emmanuele Bassi
Emmanuele Bassi
Eric Engestrom
Ross Burton
Jan Alexander Steffens (heftig)
luz.paz
Tom Schoonjans
Michał Górny