Use two levels of pthread support: a minimal level used to
build cairo itself, and a full level to build threaded apps
which want to use cairo. The minimal level tries to use
pthread stubs from libc if possible, but falls back to the
full level if that's not possible. We use CFLAGS=-D_REENTRANT
LIBS=-lpthread to find a real pthread library since that seems
to work on every unix-like test box we can get our hands on.
Currently wether internal glew is built is dependant on wether the
tarball in use was built with internal glew or not. And that's not how
it should be.
This is an attempt to fix the broken situation we've been in where
automake links libcairo.la with c++ because it might potentially maybe
include C++ files.
Those potential files only exist in Chris' throwaway backends (skia, qt)
and the BeOS backend, so for 99.99% of cases, these backends are not
needed and linking with c++ is overkill. Also, no one wants to have
libcairo.so link to libstdc++.
This patch fixes that in mutliple steps:
1) Add build infrastructure to distinguish between C and C++ backends.
This is done by allowing to specify backend_sources as well as
backend_cxx_sources variables in Makefile.sources.
2) Optionally build a libcairo_cxx.la noinst library
This intermediate library is built for C++ backends only and therefor
linked using c++. It is then linked into the final libcairo.la. This
does not require c++, so the linking of libcairo.la is done with cc.
This also works around various weirdnesses that the current build system
exposes, where it assumes cisms when in fact using c++ semantics, like
not detecting c++ properly or:
https://bugzilla.redhat.com/show_bug.cgi?id=606523
Required for successful linking of our programs. I am not sure what the
impact this has upon other users of Cairo yet, I think we need to export
the PTHREAD_CFLAGS via cairo.pc as well.
The new xcb surface uses xcb_writev() and xcb_take_socket()
which were introduced in libxcb 1.1.92. The boilerplate
in turn uses the major_code and minor_code fields in
xcb_generic_error_t, which were introduced in 1.4.
Autoconf was complaining that AC_COMPILE_IFELSE and AC_RUN_IFELSE
were called before AC_GNU_SOURCE. Moving AC_GNU_SOURCE right after
AC_INIT solves this.
drm makes use of 64bit offsets when mmaping, and so we require the
64bit file interfaces. I had presumed that it would be pulled in with
AC_GNU_SOURCE, but no.
Trying to build xcb on a system without SHM wrapped by xcb. The right
answer would be to build libxcb-shm. The quick answer is to compile out
shm support.
Still an experimental backend, it's now a little too late to stabilise
for 1.10, but this should represent a major step forward in its feature
set and an attempt to catch up with all the bug fixes that have been
performed on xlib. Notably not tested yet (and expected to be broken)
are mixed-endian connections and low bitdepth servers (the dithering
support has not been copied over for instance). However, it seems robust
enough for daily use...
Of particular note in this update is that the xcb surface is now capable
of subverting the xlib surface through the ./configure --enable-xlib-xcb
option. This replaces the xlib surface with a proxy that forwards all
operations to an equivalent xcb surface whilst preserving the cairo-xlib
API that is required for compatibility with the existing applications,
for instance GTK+ and Mozilla. Also you can experiment with enabling a
DRM bypass, though you need to be extremely foolhardy to do so.
We were using _GNU_SOURCE throughout the codebase, so simply define it
once during configure. This is the easiest method to enable recursive
mutexes using pthreads, as required in a pending patch.
Enable "ld_preload" (DYLD_INSERT_LIBRARIES + DYLD_FORCE_FLAT_NAMESPACE)
and build cairo-trace as a library instead of a module to make it
work also on MacOS X.
This appears to be the simplest mechanism to build libglew at the moment -
should a system copy be unavailable. Fortunately libglew is now distributed
under a permissive licence.
If you want to pass 'make -C src check' you have to use the system copy,
or spend quite a bit of time cairo-fying libglew.
There you go Joonas, I don't always ignore your suggestions! This is
simple patch to allow the user to disable symbol loops in case the
auto-detection fails on some obscure (perhaps OpenBSD) platform. Or in
case the user really wants to trim a few bytes from a library only used
during tracing!
Some environments may be broken beyond our capabilities to detect, or
maybe the user is just insane and doesn't want to build my nice shiny
cairo-trace. Whatever, give them the option to choose:
$ ./configure --disable-trace
For the purposes of benchmarking it is useful to run cairo-perf against a
different library from the one it was compiled against. In order to do so,
we need to check that the runtime library contains the required entry
points for our targets - which we can check by using dlsym.
