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.
Needed to allow functions outside the original XPG3 standard to be
visible in the Solaris headers when _XOPEN_SOURCE is defined and
not set to a particular value.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The strdup() function is available on uClibc if _XOPEN_SOURCE_EXTENDED
is defined; since we're using _GNU_SOURCE elsewhere to enable extended
libc features, and uClibc will set _XOPEN_SOURCE_EXTENDED if _GNU_SOURCE
is set, let's use that.
Closes#181
FreeBSD hides declarations of non-POSIX functions when POSIX macros,
such as _POSIX_C_SOURCE or _XOPEN_SOURCE, is defined. This causes
test/dlwrap.c to fail to compile because it uses dlvsym and asprintf.
Fixes: #169
If you've built Mesa with --disable-texture-float, and try to run the
tests against Xvfb, glx_public_api_core will fail: creating a direct
context with llvmpipe will fail because you don't have
ARB_texture_float, and the internal fallback to an indirect context will
fail because indirect only supports through 1.4. So the server will
throw GLXBadFBConfig at you to say "I don't support core contexts",
which we should interpret as a skip not a failure.
Signed-off-by: Adam Jackson <ajax@redhat.com>
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.
build_apple was introduced in 756dca as a proxy for the fact that Apple's libc
doesn't have dlvsym(), which is glibc-specific so also isn't present in other
libc implementations such as musl.
Instead of detecting whether we are building for Apple or not, just probe the to
see if we have dlvsym.
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.
The common EGL testing code uses XOpenDisplay(), which means we need to
explicitly include the Xlib.h header file, instead of relying on
something else stringing it along.
Add libOpenGL to the list of libraries we'll intercept. This is harmless
if glvnd is not available as the dlopen(libOpenGL.so) will fail, but
without this we can't intercept glGetString, which the
egl_and_glx_different_pointers_glx test needs to be able to do.
Signed-off-by: Adam Jackson <ajax@redhat.com>
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>
This mutes compiler warnings for `dlwrap.c` by ensuring we actually check
the return status of the `asprintf` call. At this point in the test suite
our possible failure here is only memory, so we'll abort.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
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.
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.
It's pretty much pointless to build and run tests for a library that we
know is not available.
The Meson build already skips the GLES 1.0 test, so let's make the
Autotools build do the same.
Most of the changes that happened after commit 8bbc0d40 broke epoxy
pretty much irreparably because of the CMake build and the attempt at
making libepoxy a static library that can be copy-pasted into another
project without generating files.
Since all the commits are entangled, and are full of unrelated changes,
we cannot simply do a localized set of reverts; instead, we need to hit
the reset button.
From this point forward, we're going to improve libepoxy's build while
attempting to keep the existing build system working. This may mean
reinstating the CMake build system at a later date.
These LDFLAGS go to the compiler, and getting the arg to the linker
requires -Wl or -Xlinker. gcc apparently was passing this through
anyway, while clang was getting angry.
Fixes failure of the X Server with glamor using desktop GL on EGL, and
the associated testcase in the tree. This was clearly just
copy-and-paste failure on my part in
b251e3ae33.
Eric Anholt
crziter
Alan Coopersmith
Nirbheek Chauhan
Emmanuele Bassi
Ting-Wei Lan
Adam Jackson
Ross Burton
Jan Alexander Steffens (heftig)
Michał Górny
Ikey Doherty
Efraim Flashner
Olivier Blin
Yaron Cohen-Tal
Chun-wei Fan