The code here is a complicated way to write exactly the same thing. If
`get_option('x11')` returns `disabled`, ie `-Dx11=disabled` then
`dependency()` short circuits and returns a not found object (just like
`dependency('', required : false)`, but with the correct name for error
messages).
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.
Currently, building with -Dx11=disabled or -Dx11=auto gives identical
results.
In both cases, it only makes the x11 dependency optional: It'll still
look for libx11, and if libx11 is available, then it'll still build with
X11 support enabled.
This changes the meson build so that if you pass -Dx11=disabled, then it
will use a dummy dependency for x11, which will cause it to build as if
libx11 was not available.
Remove the "If only executable code is distributed..." paragraph from
the license text. Everything now uses a normal MIT license.
The only code from Khronos that's included in libglvnd is the EGL/GL
header and XML files, which do not contain that paragraph.
Fixes https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/221
Add a 'dispatch-tls' option. Setting the option to false will force it
to use the TSD dispatch stubs for builds that would otherwise support
the TLS stubs.
This is mostly for test coverage, to make it easier to test builds that
use the __thread variable (u_current_tls.c), but still use the TSD
dispatch stubs.
Change the 'tls' option to be a boolean value instead of a feature.
This still allows manually disabling TLS in builds that would otherwise
support it, but it shouldn't be affected by meson's --auto-features
option.
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>
When building for armel, Meson's cpu() and cpu_family() strings aren't always
sufficient.
Instead, try to check for some predefined macros to determine if it's building
for ARMv7 or something older.
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.
Theres a couple of things that this meson build system does differently
than autotools. It doesn't use a config.h file, it just puts #defines on
the command line with -D. It also does all of the code generation in the
generated folder, simply because it's simpler to do that.
On my 2 core / 4 thread KBL system:
autotools (no ccache):
sh -c "./autogen.sh&& ./configure && make -j6 check" 44.74s user 6.70s system 145% cpu 35.269 total
autotools (warm ccache):
sh -c "./autogen.sh&& ./configure && make -j6 check" 32.86s user 4.22s system 129% cpu 28.580 total
meson (no ccache):
sh -c "meson build; ninja -C build test" 23.48s user 3.71s system 236% cpu 11.487 total
meson (warm ccache)
sh -c "meson build; ninja -C build test" 16.06s user 2.31s system 210% cpu 8.727 total
Kyle Brenneman