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>
The EGL_EXT_device_query extension introduces the
eglQueryDeviceStringEXT() function, which can be used with an
EGLDeviceEXT enumeration to receive an OpenGL extension string
containing all of the device extensions supported by it. From the
EGL_EXT_device_query spec's amendments to section "3.2 Devices" after
"3.1 Errors":
const char *eglQueryDeviceStringEXT(EGLDeviceEXT device,
EGLint name);
returns a pointer to a static, zero-terminated string describing
some aspect of the specified EGLDeviceEXT. <name> must be
EGL_EXTENSIONS.
Since OpenGL extension parsing is rather simple, and we could always run
into additional cases similar to this one in the future, we expose the
shared epoxy_extension_in_string() function in libepoxy's public headers
so that users can save themselves the hassle of having to write their
own extension parser.
Signed-off-by: Lyude Paul <thatslyude@gmail.com>
This code attempts not to dlopen anything if it can find the appropriate
winsys symbols in the global namespace. That's nice. However we normally
do dlopen(RTLD_LOCAL) when we open lib{GLX,EGL} so those symbols will
_not_ in fact be in the global namespace. The code also prefers checking
GLX to EGL, which means even if we initialize EGL through epoxy, and
even if we're using glvnd, we'll still dlopen libGL the first time we
hit epoxy_is_desktop_gl().
There's a couple of ways to skin this cat, let's take the easy one. If
either-but-not-both of the glx or egl handles in the global API state
are initialized, then we know we're already in one or the other. If
neither or both are initialized, then the current heuristic should work
fine.
Note that epoxy_is_desktop_gl() is only bothering to check for GLX to
work around PowerVR's broken GLES. One suspects a better way to do that
would be to check GL_VENDOR or GL_RENDERER and avoid probing the window
system at all.
Signed-off-by: Adam Jackson <ajax@redhat.com>
The EGL API update from d11104f2b5 introduced a dependency on the
EGL_CAST() macro, provided by an updated eglplatform.h. Given that we
don't provide eglplatform.h, add a fallback definition for if we're
building against Mesa 17.0.x or similar.
https://bugs.gentoo.org/show_bug.cgi?id=623926
glvnd has the rather nice property that GLX and (desktop) GL are
available in separate libraries. As an example this would allow an EGL
app to use desktop GL without any X11 libraries. Fix up our dlopens to
prefer the glvnd libraries if available and fall back to the old ABI if
not.
Signed-off-by: Adam Jackson <ajax@redhat.com>
It is perfectly possible to build Mesa3D with just OpenGL support, and
use with GLX in X.org, without having EGL/OpenGLES support.
However, libepoxy currently unconditionally requires EGL support in its
configure.ac, which causes a build failure when Mesa3D only provides
full OpenGL support:
checking for EGL... no
configure: error: Package requirements (egl) were not met:
Package egl was not found in the pkg-config search path.
Perhaps you should add the directory containing `egl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'egl', required by 'world', not found
This commit fixes that by:
- Adjusting the configure.ac to add a --{enable,disable}-egl option
handled in the exact same way as --{enable,disable}-glx
- Adjusting the meson build logic in the same way.
- Adjusting src/dispatch_common.h to define PLATFORM_HAS_EGL correctly,
which allows to not include any EGL related header file if EGL
support is not enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We can build Epoxy with different compilers on Linux, and they may not
support all the linker flags we wish to use, so we should check whether
or not they exist.
Related commit: b3b8bd9af7
Fix "epoxy_glx_version" to handle the case when GLX is not active on the display.
Patch is tweak from the original version posted by Tom Horsley
In order to properly depend on headers, both generated and provided, in
a separate directory, we need to refer to them using their path.
Generated headers already have their full path; for provided ones, we
can simply use the `files()` directive.
This change should allow using libepoxy as a Meson subproject.
Fixes: #115
We have been building the shared library for Epoxy without the symbol
visibility flags for the compiler, which means we've been leaking
internal symbols all over the floor.
Fixes: #111
Using GCC is not a guarantee of also having access to the Linux linker;
just like we use specific linker flags on macOS, the symbolic and relro
linker flags are pretty much Linux specific.
Autotools automatically adds version related linker flags on macOS that
are not related to the version information. Since we want to maintain
binary compatibility, we should do the same when building on macOS.
Fixes: #108
The code generation rules are explicitly built for each supported API
target, but they ought to be refactored since they are pretty much
identical.
In order to do that, we can store the arguments to the custom_target
rules inside an array and then iterate over each element.
This cuts down the complexity of the Meson build, and the chances of
getting something wrong due to duplication.
Instead of having Meson determine the invocator through the shebang
line we explicitly pass the script file to the Python interpreter.
This will allow us to either use Python3 or Python2, or whatever
Python.exe is available on Windows.
PyLint raises a bunch of issues on the dispatch generation script with
regards to best practices; most of those issues are real, so let's fix
the code to be more Pythonic.
Currently, GLX support in libepoxy at build time is hard coded, but
various platforms have expressed their preference for having a
configure-time option for it.
For instance:
- various embedded distributors do not ship with X11, but wish to use
libraries that depend on libepoxy now that Wayland is available
- distributors for macOS still wish to retain the ability to ship
their software with X11 enabled
By default, we want epoxy to build with GLX enabled pretty much
everywhere it makes sense, since it's only a build-time option and it's
not a run-time dependency.
Libraries and applications that depend on Epoxy currently have no way to
safely degrade functionality if they are used on a platform without GLX
support; the only way to achieve that is to perform a symbol check
themselves, by essentially copying what Epoxy already does.
By exposing `epoxy_has_glx()`, those libraries and applications now have
the chance of querying Epoxy itself and gracefully handle failure.
When checking whether GLX or EGL are available on the system, we don't
want to use the internal API that forces an exit() on missing libraries
and symbols — as that would defeat the point.
Instead, we should have safe functions to call internally that simply
return a NULL pointer, so we can bail out ourselves in a controlled
fashion.
The new GL registry XML contains the 'glsc2' identifier for the OpenGL
SC 2.0 API. We can safely ignore it, since we don't really know what to
do with it, at the moment.
On UNIX-like OSes, the OS will read the shebang and use the correct
interpreter, and on Windows, Meson will read the shebang and use the
correct interpreter.
Adding it manually will cause python to try to interpret python
Adam Jackson
Emmanuele Bassi
Ross Burton
luz.paz
Tom Schoonjans
Robert Bragg
Ikey Doherty
danem
Lyude Paul
Daniel Stone
Thomas Petazzoni
Gianfranco Costamagna
Nirbheek Chauhan