Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-and-Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
For the sake of consistency.
Tested-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-and-Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This ensures that GLES1-only typedefs are available in these files.
In a future patch, this will allow us to expand the dispatch table to
include GLES1-only functions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
These are largely based on the src/mapi/glapi/tests. However,
shared-glapi provides less external visibility into the dispatch table,
so there is less to test. Also, shared-glapi does not implement
_glapi_get_proc_name, so that test was removed.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
We already provided these files on 'make install', but only created a
'libglapi.so' in the top-level lib/ convenience folder. We used to
create all three, but at some point in the build system churn, it broke.
Various applications (like the ES2 conformance suite) seem to link
against libglapi.so.0, so without these links, setting LD_LIBRARY_PATH
and LIBGL_DRIVERS_PATH can lead to using /usr/lib/libglapi.so.0 with
/home/whatever/libGL.so, which leads to API calls getting routed
incorrectly (i.e. glCompileShader -> _mesa_LinkProgramARB), which leads
to rage problems.
Preserve developer sanity...install links.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Use -no-undefined to assure libtool that the library has no unresolved
symbols at link time, so that libtool will build a shared library on
platforms that require that all symbols are resolved when the library
is linked.
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
This fixes a build problem where EGL links to libgbm.la, which encodes
a relative path to it's libglapi.so dependency. The relative path
breaks when the linker tries to resolve it from src/egl/main instead
of src/gbm. Typically we silently fall back to the system
libglapi.so, which is wrong and breaks when there isn't one.
Morale of the story: don't mix mklib and libtool.
glapi_gen.mk is supposed to be included by glapi users to simplify
header generation. This commit also makes es1api, es2api, and
shared-glapi use it.
Reviewed-by: Brian Paul <brianp@vmware.com>
[olv: updated after reviewing to prefix all variables in glapi_gen.mk by
glapi_gen]
makedepend would crash when a source includes a header indirectly, such
as
#define HEADER "some-header.h"
#include HEADER
Do not define HEADER (makedepend would detects this as an incomplete
include) and add the dependency manually in the Makefile.
This should hopefully fix bug #33374.
GLES can be enabled by running scons with
$ scons gles=yes
When gles=yes is given, the build is changed in three ways. First,
libmesa.a will be built with FEATURE_ES1 and FEATURE_ES2. This makes
DRI drivers and libEGL support and advertise GLES support. Second, GLES
libraries will be created. They are libGLESv1_CM, libGLESv2, and
libglapi. Last, libGL or opengl32 will link to libglapi. This change
is required as _glapi_* will be declared as __declspec(dllimport) in
libmesa.a on windows. libmesa.a expects those symbols to be defined in
another DLL. Due to this change to GL, GLES support is marked
experimental.
Note that GLES requires libxml2-python to generate some of its sources.
When --enable-shared-glapi is specified, libGL will share libglapi with
OpenGL ES instead of defining its own copy of glapi. This makes sure an
app will get only one copy of glapi in its address space.
The new option is disabled by default. When enabled, libGL and libglapi
must be built from the same source tree and distributed together. This
requirement comes from the fact that the dispatch offsets used by these
libraries are re-assigned whenever GLAPI XMLs are changed.
For GLX, indirect rendering for has_different_protocol() functions is
tricky. A has_different_protocol() function is assigned only one
dispatch offset, yet each entry point needs a different protocol opcode.
It cannot be supported by the shared glapi. The fix to this is to make
glXGetProcAddress handle such functions specially before calling
_glapi_get_proc_address.
Note that these files are automatically generated/re-generated
src/glx/indirect.c
src/glx/indirect.h
src/mapi/glapi/glapi_mapi_tmp.h
Move _glapi_* symbols from libGLESv1_CM.so and libGLESv2.so to
libglapi.so. This makes sure an app will get only one copy of glapi in
its address space.
Note that with this change, libGLES* and libglapi must be built from the
same source tree and distributed together. This requirement comes from
the fact that the dispatch offsets used by these libraries are
re-assigned whenever GLAPI XMLs are changed.
