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
To avoid a symbols file on Windows, Epoxy annotates all the publicly
visible symbols directly in the source, but uses the default symbol
visibility everywhere else. This means that only some symbols are
annotated as `EPOXY_IMPORTEXPORT`, and generally only on Windows.
Additionally, Epoxy has a private 'PUBLIC' pre-processor macro for
internal use, which duplicates the `EPOXY_IMPORTEXPORT` but contains
more logic to detect GCC, in case we're building with GCC on Windows.
This would be enough, except that EGL is also available on Windows,
which means we'd have to annotate the exported `epoxy_*` API inside
epoxy/egl.h as well. At that point, though, we should probably avoid
any confusion, and adopt a single symbol visibility policy across the
board.
This requires some surgery of the generated and common dispatch sources,
but cuts down the overall complexity:
- there is only one annotation, `EPOXY_PUBLIC`, used everywhere
- the annotation detection is done at Epoxy configuration time
- only annotated symbols are public, on every platform
- annotated symbols are immediately visible from the header
We need to explicitly link against gdi32 in order to access
SetPixelFormat and ChoosetPixelFormat, and the order of the linking is
relevant when using static libraries. This is a slight workaround to the
order of compiler arguments generated by Meson, and it's supposed to go
away in the near future.
Instead of using a generator and having to deal with tweaking the
inclusion paths, we can use a custom target rule, which will do the
right thing and put the generate files where we expect them to be.
Due to how Meson and Ninja work we need to be a bit more careful as to
how we deal with dependencies and generated files, especially since
Epoxy is built on the assumption that the only inclusion path for the
headers lies under the 'include' sub-directory.
First of all, we need to split the dispatch table generation into two
separate steps, one for the headers and one for the source files.
Additionally, we need to munge the paths of the non-generated headers
so that we reference them by their correct path.
These changes are necessary to ensure that Epoxy can be built on a
system without Epoxy installed already; the previous Meson-based build
system relied on the headers being installed in a system directory.
Meson is a Python-based build system that generates build rules of
Ninja, Visual Studio, and XCode. It's designed to be fast, and have a
small, non-Turing complete language to describe the build process,
tests, and dependencies. It's simpler than CMake, and faster than
autotools.
As a direct comparison in terms of speed, three build and check runs for
libepoxy from a clean Git repository clone yield these results on my
Kabylake Core i7 7500U (nproc=4):
- Autotools (make)
Run #1 (cold) real: 22.384s, user: 20.011s, sys: 3.689s
Run #2 (warm) real: 22.429s, user: 20.220s, sys: 3.708s
Run #3 (warm) real: 22.068s, user: 19.743s, sys: 3.594s
- Meson (ninja)
Run #1 (cold) real: 5.932s, user: 9.371s, sys: 1.625s
Run #2 (warm) real: 6.273s, user: 10.066, sys: 1.740s
Run #3 (warm) real: 5.796s, user: 9.233s, sys: 1.607s
Which means that Meson and ninja are approximately 4x faster than
autotools.
In terms of simplicity, the autotools build takes six files and a total
of 645 lines; Meson requires 3 files, and 361 lines to achieve the same
result. Additionally, Meson automatically builds in a separate build
directory and does not leave files inside the source directory; and Meson
does not use libtool.
Since Meson is quite new and still actively developed, we're going to
leave the autotools build in place for a while, with the intention of
switching to Meson in the future.
The gen_dispatch.py script relies on the source and include directories
to exist before dumping the files in there, split by type, in order to
sustain the split of the headers existing in a separate root from the
source files. This causes a spooky-action-at-a-distance scenario where
headers are generated by rules inside the source directory but influence
the contents of a separate directory — and require a separate set of
rules to install those headers.
Different build systems would require either splitting the generation in
to two separate passes (which is more expensive and time consuming), or
generate the header and source files in the same directory, and just
tweak the inclusion paths accordingly.
Since we want to maintain this fiction for the autotools build, but
ignore it for different build systems, let's add a separate set of
arguments for gen_dispatch.py that make the rules inside Makefile.am
work appropriately.
Define PACKED for Visual Studio builds, so that we can try to reduce
our library size for Visual Studio builds. Add a ENDPACKED macro
that is currently defined only for Visual Studio builds as packing is
done via __pragma(pack(push,n), that should be popped when done.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Certain X server do not have GLX enabled or supported, such as x2go. We
can handle this case gracefully inside libepoxy.
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
EGL is available on different platforms, so we should favor it, if
available. This also allows us to decouple EGL from GLX, and use the
former without the latter being compiled in.
Emmanuele Bassi
Robert Bragg
Ikey Doherty
danem
Adam Jackson
Lyude Paul
Daniel Stone
Tom Schoonjans
Thomas Petazzoni
Gianfranco Costamagna
Nirbheek Chauhan
Patrick Griffis
Chun-wei Fan
Yaron Cohen-Tal