summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* meson: Override dependency to improve usage as a subprojectNirbheek Chauhan2022-12-181-0/+1
| | | | | | | | | | | | | | | | With this change, libepoxy can be consumed as a subproject without making any changes to the build files of a project. All you need to do is provide a wrap file with a `[provide]` section: https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section This is also necessary because otherwise projects need to hard-code the subproject name, which might be `libepoxy` when using `wrap-git` or `libepoxy-1.5.10` when using `wrap-file` (to build from a release tarball). This can cause conflicts between different subprojects that consume libepoxy differently. Other projects like glib, cairo, pango, etc already do this.
* Add the right include paths for EGL and X11 headersAlex Richardson2022-02-161-0/+6
| | | | | | | | | | | | | | 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.
* fix error: use of undeclared identifier 'OPENGL_LIB'Caolán McNamara2021-10-201-0/+4
| | | | | at epoxy/src/dispatch_common.c:690 in LibreOffice android build with libepoxy-1.5.9
* Allow libopengl.so to be used when GLX_LIB is missingJohn Bates2021-07-021-3/+13
| | | | | | | | | | | | | | | 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>
* Revert "If glvnd library found, do not use libGL.so in epoxy_load_gl"Emmanuele Bassi2021-05-211-6/+3
| | | | | | | | | Commit dbfa4b20 has introduced a string of regressions in the X server and KWin. This reverts commit dbfa4b209c0712b67dfeb8366c2ebe8503063b52. See: #252
* Revert "Do not overwrite glx_handle in epoxy_load_gl if GLX library is ↵Emmanuele Bassi2021-05-211-2/+1
| | | | | | loaded already" This reverts commit 4994c48172e94ca81c000597e0abc0ea0e682b3c.
* Remove redeclaration of khronos_uintptr_tebassi/issues-249Emmanuele Bassi2021-04-301-1/+0
| | | | | | | The type is being redeclared because I didn't see the original declaration when I wrote 144cbc9325250081f2eb584ca5deb13aaf1c2433. Fixes: #249
* Merge pull request #247 from anholt/win64-khr-types1.5.6Emmanuele Bassi2021-04-191-3/+11
|\ | | | | Support Win64 pointer-sized types
| * Support Win64 pointer-sized typeswin64-khr-typesEmmanuele Bassi2021-03-211-3/+11
| | | | | | | | | | | | | | | | 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
* | gen_dispatch.py: close output filesAleksandr2021-03-061-0/+10
| | | | | | | | Fixes https://github.com/anholt/libepoxy/issues/242
* | Merge pull request #238 from anholt/pull-229-altEmmanuele Bassi2021-01-201-3/+7
|\ \ | | | | | | Fix some bugs in loading OpenGL/GLX/EGL libraries
| * | Do not overwrite glx_handle in epoxy_load_gl if GLX library is loaded alreadypull-229-altYaroslav Isakov2021-01-201-1/+2
| | | | | | | | | | | | | | | | | | Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
| * | If glvnd library found, do not use libGL.so in epoxy_load_glYaroslav Isakov2021-01-201-3/+6
| |/ | | | | | | | | | | | | | | | | | | 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>
* | meson: Set same variables in declare_dependency() as in pkgconfigXavier Claessens2021-01-201-4/+9
|/ | | | | | | | | 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().
* Use Meson's darwin_versions argumentdarwin_versionsEmmanuele Bassi2020-07-211-3/+2
| | | | | Instead of tweaking the linker flags ourselves. This allows Meson to do the right thing, and pass the arguments only where needed.
* Fix return value of shading language for GLES2.glslesEric Anholt2020-04-201-10/+5
| | | | | | | 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.
* Use EGL_NO_X11 to disable X11 headersEmmanuele Bassi2020-01-141-3/+6
| | | | | | | MESA_EGL_NO_X11_HEADERS has been deprecated, and libglvnd only supports EGL_NO_X11. Fixes: #214
* Remove the autotools build system.Eric Anholt2019-11-261-184/+0
| | | | Meson has been out for a long time, is faster, and is simpler.
* Remove Python 2 supportEmmanuele Bassi2019-11-142-1/+1
| | | | | Python 2 is going to reach EOL in January 2020, and most platforms have already moved to Python 3.
* Reuse the enum_strings in looking for extension providers.Eric Anholt2019-06-251-4/+7
| | | | | | | | | Shaves another 14k off the binary: 1114236 56800 160 1171196 11defc providernames.so 1099948 56800 160 1156908 11a72c enumstrings.so Fixes #202
* Drop "GL extension" and "GLX extension" and such from the debug output.Eric Anholt2019-06-251-8/+4
| | | | | | | | 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
* Make the provider enums have a PROVIDER_ prefixEric Anholt2019-06-251-1/+2
| | | | This will distinguish them from the exposed extension presence
* build: Drop conditional use of get_supported_link_arguments()meson-bumpEmmanuele Bassi2018-10-041-5/+1
| | | | Meson complains even in the face of a version check.
* dispatch_common: fix conditional compilationZhao Zhili2018-07-161-2/+2
|
* dispatch: Fix GLES3 symbol lookupAdam Jackson2018-07-061-1/+1
| | | | | Looking for a symbol named "libGLESv2.so.2" is probably not going to work very well.
* Use the appropriate symbols on __APPLE__Emmanuele Bassi2018-05-291-13/+18
| | | | | | | | | | 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
* Disable EGL on macOSEmmanuele Bassi2018-05-291-1/+1
| | | | EGL is not available on macOS, except through Objective C.
* dispatch: Try harder to avoid calling the resolver1.5.2Adam Jackson2018-05-171-3/+5
| | | | | | | | | | | | | | 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>
* Use -Bsymbolic-functions instead of -BsymbolicEmmanuele Bassi2018-05-172-3/+3
| | | | | | | | | | | | | 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
* Use abort() instead of exit(1)Emmanuele Bassi2018-05-171-3/+3
| | | | | | 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.
* dispatch: Load EGL/GLX provider lib from epoxy_has_{egl,glx}()Adam Jackson2018-05-014-28/+35
| | | | | | | | | 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>
* dispatch: Stop implicitly loading libraries from do_dlsymAdam Jackson2018-05-011-32/+55
| | | | | | | 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>
* dispatch: Be even gentler about probing for GLXAdam Jackson2018-04-301-34/+7
| | | | | | | | | | | | | | | | | 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>
* dispatch: Query the EGL context version when bootstrapping on GLESAdam Jackson2018-04-301-10/+10
| | | | | | | | | | | | | | 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: Fix the -z,relro flagEmmanuele Bassi2018-04-251-1/+1
| | | | We're missing a dash.
* meson: Conditionally test for linker flagsEmmanuele Bassi2018-04-251-6/+6
| | | | | | | | 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.
* dispatch: assert, not errx, when we have no contextAdam Jackson2018-04-121-1/+1
| | | | | | errx() calls exit(), you'd rather get a backtrace. Signed-off-by: Adam Jackson <ajax@redhat.com>
* Merge pull request #156 from tschoonj/fix-gl-pkgconfig-macosEmmanuele Bassi2018-03-121-2/+2
|\ | | | | meson: do not add gl to pkg-config file on macOS
| * meson: do not add gl to pkg-config file on macOSTom Schoonjans2018-03-041-2/+2
| | | | | | | | | | | | | | 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.
* | Merge pull request #159 from luzpaz/misc-typosEmmanuele Bassi2018-03-121-1/+1
|\ \ | | | | | | Trival misc. typo fixes
| * | Trival misc. typo fixesluz.paz2018-03-051-1/+1
| |/
* | autotools: check for dlvsymRoss Burton2018-03-121-0/+0
|/ | | | | | 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.
* Support encoding minor versions bigger than 10Emmanuele Bassi2018-02-241-3/+9
| | | | | | | | | | | 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.
* Fix epoxy_internal_gl_version()Emmanuele Bassi2018-02-241-1/+1
| | | | The glGetString() function takes a GLenum, so we should too.
* Do not use OPENGL_LIB on AndroidEmmanuele Bassi2018-02-231-0/+2
| | | | | | | | 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
* Document epoxy_set_resolver_failure_handler()Emmanuele Bassi2018-02-231-0/+7
|
* Add epoxy_glsl_version()Emmanuele Bassi2018-02-231-4/+29
| | | | | | | | 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
* docs: Update the supported GL version to 4.6Emmanuele Bassi2018-02-231-1/+1
|
* Allow building Epoxy without X11Emmanuele Bassi2018-02-231-0/+7
| | | | | | | | | 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.
* Add gl and egl private dependenciesEmmanuele Bassi2018-02-231-0/+12
| | | | | | | | | | | | | | | 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
View Lorry Controller Status