summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* meson: Generate the pkg-config fileEmmanuele Bassi2018-02-231-28/+35
| | | | | | | | 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.
* Merge pull request #143 from ikeydoherty/comp-warningsEmmanuele Bassi2018-02-232-5/+4
|\ | | | | Fix printf family usage
| * Only use printf family when passing argumentsIkey Doherty2017-10-192-5/+4
| | | | | | | | | | | | | | 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>
* | Check __ANDROID__ define when guarding Android codeRobert Bragg2018-01-181-3/+3
|/ | | | | | 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.
* Merge pull request #136 from Lyude/pull/epoxy_ext_in_strEmmanuele Bassi2017-10-192-2/+18
|\ | | | | Expose epoxy_extension_in_string() in public headers
| * Expose epoxy_extension_in_string() in public headersLyude Paul2017-08-242-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Fix pointer mismatch bug on Windows 10. danem2017-10-131-1/+1
| | | | | | We must explicitly cast to void**
* | Merge pull request #131 from nwnk/nonfatal-resolve-handlerEmmanuele Bassi2017-09-113-0/+24
|\ \ | | | | | | RFC: Add epoxy_set_resolver_failure_handler()
| * | Add epoxy_set_resolver_failure_handler()Adam Jackson2017-07-143-0/+24
| | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com>
* | | dispatch: Fix the libOpenGL sonameAdam Jackson2017-09-071-1/+1
| |/ |/| | | | | Brown-paper-bag-for: Adam Jackson <ajax@redhat.com>
* | Merge pull request #134 from fooishbar/add-eglcast-defEmmanuele Bassi2017-07-211-0/+9
|\ \ | |/ |/| Add fallback definition for EGL_CAST
| * Add fallback definition for EGL_CASTDaniel Stone2017-07-071-0/+9
| | | | | | | | | | | | | | | | | | 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
* | dispatch: Be more paranoid about detecting GLX or notAdam Jackson2017-07-121-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | dispatch: Use epoxy_conservative_glx_dlsym when probing GLXAdam Jackson2017-07-121-13/+13
| | | | | | | | | | | | This path should also only load libGLX.so if possible. Signed-off-by: Adam Jackson <ajax@redhat.com>
* | dispatch: Don't reference glvnd #defines on non-glvnd systemsAdam Jackson2017-07-121-0/+2
|/ | | | | | | Broke the build on OSX, oops. Resolves: https://github.com/anholt/libepoxy/issues/132 Signed-off-by: Adam Jackson <ajax@redhat.com>
* dispatch: Learn about glvndAdam Jackson2017-06-161-5/+26
| | | | | | | | | | 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>
* meson.build: fix macOS common_ldflagsTom Schoonjans2017-06-121-1/+1
| | | Equal signs are not accepted by the macOS linker: spaces must be used instead.
* Make EGL support optionalThomas Petazzoni2017-05-171-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* build: Check for linker flags on LinuxEmmanuele Bassi2017-05-021-1/+5
| | | | | | 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.
* epoxy_internal_has_gl_extension, epoxy_egl_version: add some missing ↵Gianfranco Costamagna2017-04-242-1/+11
| | | | | | | | nullpointer checks from https://bugzilla.redhat.com/show_bug.cgi?id=1395366 Related commit: b3b8bd9af7bf1fcfe544fd131f4d4f0d117ae7bc 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
* Move epoxy_headers definition into include/epoxyEmmanuele Bassi2017-03-281-4/+0
| | | | | | | | | | | | 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
* Add missing visibility compiler flagsEmmanuele Bassi2017-03-091-3/+1
| | | | | | | | 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
* Use some linker flags only on LinuxEmmanuele Bassi2017-03-071-1/+2
| | | | | | 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.
* Add explicit version flags for macOS buildsEmmanuele Bassi2017-03-071-2/+6
| | | | | | | | 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
* Add z,relro and z,now to the GCC linker flagsEmmanuele Bassi2017-03-031-1/+1
| | | | | | | | | | | | | These flags are mitigations against memory corruption bugs, and are typically enabled by Linux distributions hardening rules. We only use these flags with GCC, similarly to `-Bsymbolic`. More information on relro is available here: - http://tk-blog.blogspot.co.uk/2009/02/relro-not-so-well-known-memory.html - http://mudongliang.github.io/2016/07/11/relro-a-not-so-well-known-memory-corruption-mitigation-technique.html - https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_RELRO_.28ld_-z_relro.29
* Simplify the code generation rules for MesonEmmanuele Bassi2017-03-011-67/+35
| | | | | | | | | | | | 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.
* Remove the shebang from gen_dispatch.pyEmmanuele Bassi2017-02-152-1/+4
| | | | | | | | 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.
* Annotate new Epoxy symbolsEmmanuele Bassi2017-02-152-0/+4
| | | | API added in 1.4 should be annotated as such.
* Update gen_dispatch after a pass of pylintEmmanuele Bassi2017-02-081-46/+44
| | | | | | 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.
* Merge pull request #100 from centricular/fix-find_programEmmanuele Bassi2017-02-081-4/+0
|\ | | | | meson: Don't call find_program objects with python
| * meson: Don't call find_program objects with pythonNirbheek Chauhan2017-01-281-4/+0
| | | | | | | | | | | | | | | | 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
* | Add API to allow for platform detectionEmmanuele Bassi2017-02-064-3/+62
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Linux and other Unix variants we may not have access to GLX and EGL at run time. Dependent libraries can only discover this by using dlsym() on various symbols, because as soon as they attempt to call those symbols through Epoxy, Epoxy will abort. This means that a bunch of code needs to be copy-pasted between projects, with the high chance of somebody getting it wrong. Epoxy already has all the internals needed to detect whether GLX and EGL are available, so exposing a simple API is a better alternative. Fixes #73
| * | Add epoxy_has_egl()Emmanuele Bassi2017-02-031-0/+21
| | | | | | | | | | | | Similar to `epoxy_has_glx()`, but for the EGL windowing system API.
| * | Add epoxy_has_glx()Emmanuele Bassi2017-02-031-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Add conservative functions for checking platform symbolsEmmanuele Bassi2017-02-032-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | Drop additional stdbool.h include directivesEmmanuele Bassi2017-02-031-2/+0
| | |
* | | Allow enabling and disabling GLX supportEmmanuele Bassi2017-02-061-5/+3
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Write the API referenceEmmanuele Bassi2017-02-033-12/+169
| | | | | | | | | | Now that we have Doxygen generating it, we should fill out the API reference for Epoxy.
* | Merge branch 'symbol-visibility'Emmanuele Bassi2017-01-317-37/+27
|\ \
| * | Improve consistency of the symbol visibilityEmmanuele Bassi2017-01-257-37/+27
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | gen_dispatch: Ignore 'glsc2' APIEmmanuele Bassi2017-01-311-0/+2
| | | | | | | | | | | | 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.
* | build: Clean up some Meson usagePatrick Griffis2017-01-271-4/+4
|/
* build: Explicitly link against gdi32Emmanuele Bassi2017-01-251-2/+1
| | | | | | | | 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.
* build: Rework the build rules for generated files in MesonEmmanuele Bassi2017-01-252-47/+101
| | | | | | | | | | | | | | | | | | | | | 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.
* build: Add Meson build filesEmmanuele Bassi2017-01-251-0/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* build: Split arguments for dispatch generatorEmmanuele Bassi2017-01-252-9/+33
| | | | | | | | | | | | | | | | | | | | 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.
* MSVC Builds: Support PACKEDChun-wei Fan2017-01-252-0/+7
| | | | | | | | | 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>
* build: Hide mkdirEmmanuele Bassi2017-01-251-1/+4
| | | | | We don't really need to mess the log when creating the include directory in the build directory.
* Ensure we don't assert if GLX is not availableEmmanuele Bassi2017-01-251-0/+6
| | | | | | | 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>
* Do not call errx() on platforms without itEmmanuele Bassi2017-01-251-1/+1
| | | | Like, say, Windows.
View Lorry Controller Status