| Age | Commit message (Collapse) | Author |
|---|
|
Otherwise consumers have to, and that's lame.
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
|
also link osmesa with C++ standard libraries, as it now contains C++ code
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
|
|
|
|
When building OSMesa and xlib GL, the resulting OSMesa would be linked
against libGL instead of the internal mesa libraries. However, when
building with -fvisibility=hidden, some of the internal functions used
in OSMesa could not be resolved through libGL.
Instead, always build OSMesa standalone without linking against libGL.
This has the advantage that OSMesa is always built the same way, but it
means that disk space is wasted when libGL is installed since both
libraries will contain the internal objects.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Tested-by: Tom Fogal <tfogal@alumni.unh.edu>
|
|
Move glapi to src/mapi/{glapi,es1api,es2api}.
|
|
Signed-off-by: Jeremy Huddleston <jeremyhu@freedesktop.org>
|
|
|
|
autoconf had been designating the 8 bit libOSMesa as the default
standalone osmesa, but the Makefile expected it to be linked to libGL.
Fix up the osmesa Makefile so that it allows any of the combinations of
standalone and channel width to be built.
Fixes bug #21980.
|
|
|
|
|
|
This just makes the use of mklib more consistent throughout Mesa where
we always want to pass the linker and LDFLAGS when we might be making a
shared library.
|
|
Respect the user's choice of shell when running mklib rather than always
using /bin/sh.
|
|
This removes some cruft from src/mesa/Makefile.
Something similar could be done for stand-alone / Xlib-Mesa libGL...
|
