If x11 support is enabled, then the meson and configure scripts will set
a macro named ENABLE_EGL_X11 instead of USE_X11.
USE_X11 will also select the Xlib typedef of EGLNativeDisplayType in
eglplatform.h, and libglvnd does not need or want those.
Enabling or disabling X11 support for EGL only affects platform
detection in eglGetDisplay. The rest of libEGL is supposed to treat
EGLNativeDisplayType as an opaque void* pointer.
TLSDESC speeds up access to global-dynamic TLS. TLS asm stubs do not
support TLSDESC, but all accesses are to initial-exec symbols anyways,
so it is not necessary to handle that separately.
It is not portable to use initial-exec TLS in dlopened libraries. glibc
and FreeBSD allocate extra memory for extra initial-exec variables
specifically for libGL, but other libcs including musl do not.
Since TLS entry asm assumes IE TLS, use TSD asm in other cases. Update
autoconf to match meson logic: enable ELF TLS if it is supported,
regardless of which type of asm is being used.
Added a --disable-entrypoint-tracking configure option and an
'entrypoint-patching' meson option to disable libGLdispatch's entrypoint
patching at build time.
If entrypoint patching is disabled, then it #ifdef's out the mprotect call, and
acts as if mprotect had failed, which causes libGLdispatch to skip trying to
perform any patching.
Fixes https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/217
The set of warnings emitted are dependent on compiler version,
optimization level, CPU architecture, dependency versions, etc. It's not
tractable for a code base to be warning free under all circumstances,
and it's widely agreed that -Werror should not be enabled by default.
Given that it's trivial for developers to enable -Werror for autotools
by settings CFLAGS=-Werror and for meson with -Dwerror=true we should
not enable -Werror by default and require builders to disable it.
See https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed
Reviewed-by: Eric Anholt <eric@anholt.net>
These entry points are actually not little endian specific,
but they are specific to ELFv2 ABI. ELFv2 ABI can be used
on either little or big endian, and there are distributions
doing so (e.g. Void Linux, Adélie Linux) as well as other
OSes transitioning (FreeBSD).
These have been confirmed to work on a Power Mac G5 running
Void Linux.
These use the symbol-check.py script from mesa, and should help to
ensure that glvnd doesn't start exposing/hiding new symbols. It's also
useful to double check that meson and autotools are doing the same
thing.
Change the configure script to define the EGL_NO_X11 macro unconditionally, so
that the EGL headers don't try to include the Xlib headers.
Regardless of whether --disable-x11 is used, libglvnd doesn't need X11-specific
typedefs for EGLNativeDisplayType et. al.
Define a new USE_DISPATCH_ASM macro in config.h if assembly dispatch stubs are
enabled. Update the GLX entrypoint generation to use that macro instead of
checking all of the USE_*_ASM macros.
This is less likely to break if we add assembly support for another
architecture. In addition, it'll make it easier to skip any unit tests
that depend on being able to generate new dispatch stubs.
Because mesa can be built without glesv1 so it breaks autodetection.
Fixes: https://bugs.archlinux.org/task/64032 ('mesa-demos doesn't build, unable to find GLES/gl.h')
The configure script now checks the environment variable GLDISPATCH_PAGE_SIZE.
If it's set, then it overrides the GLDISPATCH_PAGE_SIZE macro used in
libGLdispatch to align the assembly dispatch stubs.
This is mainly useful on ppc64le and aarch64 builds, where the page size can
vary.
Add a new configure option, --disable-x11. That option will disable GLX, and
will #ifdef out the X11 platform detection in EGL, but also remove the
dependency on the X11 libraries and headers.
In addition, only check for the xext and glproto packages if GLX is enabled,
since that's the only component that needs them.
This preserves the names from Mesa's gl, glesv1_cm, glesv2, and egl pkgconfig
data, and for compatibility with that, gl.pc gives you libGL.
Also added glx.pc and opengl.pc for libglvnd's libGLX and libOpenGL libraries.
If newer applications want to explicitly depend on libGLX and the appropriate
rendering API they can ask for the new pkgconfig names.
Note that the version numbers in each file are the API versions that each
library exposes, not the libglvnd package version.
An added advantage to this is that it makes it really easy to build with
Python 3, the same way other Autotools projects support it:
$ export PYTHON=/usr/bin/python3
$ ./configure
Add an AC_CHECK_FUNC call to check whether dlopen is available without any
additional libraries. Some systems provide dlopen as part of libc, in which
case we can't (and don't need to) link against libdl.so.
Added the files and makefile changes needed for adding support for ppc64le
dispatch stubs.
The actual assembly code still needs to be written, along with any other
arch-specific requirements for self-modifying code.
The new entry_ppc64le_*.c files are mostly based on the x86-64 files.
It still needs:
- Assembly code for OpenGL dispatch stubs in entry_ppc64le_tls.c,
entry_ppc64le_tsd.c, or both.
- Assembly code for GLX dispatch stubs in glvnd_genentry.c.
- Assembly code for the entrypoint patching tests in patchentrypoints.c.
Added three new configure options to disable building the EGL, GLX, GLES
libraries.
In the tests makefile, move the list of test scripts to separate unconditional
variables, and add those to EXTRA_DIST. Just conditionally adding variables to
TESTS isn't enough to include the test scripts in the dist package.
Fix the generated code for the x86 TLS dispatch stubs.
Update the x86 TLS stubs to use the same common code as the rest of the x86 and
x86-64 entrypoints.
Fixes https://github.com/NVIDIA/libglvnd/issues/18
Changed the default vendor config paths to be based on the directory options
for configure. libEGL will now look under the sysconfigdir and datadir paths,
in a "glvnd/egl_vendor.d" subdirectory.
Added the "datadir" variable to the pkg-config file, so that other packages can
find the expected location of the JSON files.
yes，i Do