We don't use it anywhere outside of the image surface, so there's no
need to make it a project-wide private function.
The name is also updated: it's a cairo function, so it should not abuse
the pixman namespace.
The previous commit touched the list of packages that are installed in
our build container. This commit changes FDO_DISTRIBUTION_TAG to ensure
the container is rebuild with those changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in fdr.c is meant to interpose function calls, e.g. it defines
a cairo_create() function that records the call and then calls the real
cairo_create() (via dlsym(RTLD_NEXT)).
This obviously does not work in a static library. This was reported in
issue #791. This commit fixes that issue by always building this as a
shared library, even when -Ddefault_library=static is passed to meson.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit dfc15dd2e5.
The code in fdr.c is supposed to interpose function calls into cairo.
I.e., instead of calling cairo_create(), the application would call into
fdr.c, this call would be recorded, and then the call is forwarded to
the real cairo_create().
The commit that is being reverted here just completely broke this by
renaming the functions. Thus, no more interposition would happen.
../src/cairo-pdf-surface.c: In function '_cairo_pdf_surface_open_content_stream':
../src/cairo-pdf-surface.c:2537:45: error: format not a string literal and no format arguments [-Werror=format-security]
2537 | str);
| ^~~
cc1: some warnings being treated as errors
The Cairo FDR trampoline code overwrites the public Cairo API used by
cairo-sphinx in order to trace the calls; when building cairo-sphinx
against a static build of Cairo, we end up with duplicated symbols.
To avoid that, we can rename the symbols to avoid the conflict, and then
provide the original symbol as a C pre-processor macro.
Fixes: #791
The 'tee' surface is used by Firefox and Thunderbird, so we should at
least have it built automatically, to ensure we catch eventual build
issues.
Tee does not have specific tests, so this does not influence our test
suite.
The master/slave terms are both inappropriate and inaccurate: the tee
surface replicates the rendering commands from a primary surface to
other surfaces.
This change is a mechanical search-and-replace.
We should default on every platform we care about to hidden symbols, to
avoid leaking private symbols.
On Windows this is the default state of affairs with the MSVC toolchain;
with GCC and GCC-compatible toolchains, we need to opt into this
behaviour. Luckily for us, Cairo already has an annotation for public
symbols, so we can easily tweak it to include the visibility attribute.
When building ancillary libraries as part of the Cairo compilation on
Windows, we use a pre-processor symbol to ensure that we keep the
dllexport annotation. This avoids including the cairoint.h header file.
Fixes: #582
The cairo-boilerplate static library cannot use private API defined in
the main Cairo shared library, because it has no access to those
symbols.
Since the code is small, we can just dump it into the boilerplate
library.
The original "slim" symbol rewriting was added without any shred of a
set of performance evaluation, and mostly copy-pasted from a very early
version of pixman. Pixman itself never used them, and most C
libraries—like GLib and GTK—have dropped similar mechanisms over the
past 15 years, as linkers have improved considerably in the meantime.
Modern linkers provide functionality to avoid intra-library PLT jump
through flags like `-Bsymbolic-functions`; we should use that, instead,
and keep the code base more maintainable and debuggable.
The old Autotools build generated a cairo-supported-features.h file for
the benefit of gtk-doc. These days, with a smaller features set, we can
get away with an override file.
Fixes: #642
Andreas Falkenhahn reported the issue below and indicated that the color
channels are swapped. This commit fixes the byte swap.
The problem is that be32_to_cpu() is a no-op on big endian systems.
However, we also have a bswap_32() function available that always works.
Testing done: None by me, but Andreas Falkenhahn reported that his patch
fixes colors on a PowerPC system.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/787
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit f6a3f6d8ad
"Don't build fontconfig on Windows" made an attempt to prevent Meson
from automatically building Fontconfig as a subproject on Windows when
the 'fontconfig' option has its default value of 'auto'.
Unfortunately, this only made things worse instead of fixing them.
Meson feature options can have three states: 'enabled', 'auto', and
'disabled'. They are primarily intended to be used as a value for the
'required' option of the 'dependency()' function. When the system
dependency is not found, but a fallback subproject is provided
explicitly with the 'fallback' option, a feature option in the 'auto'
state still causes the subproject to get built.
Since there's no apparent way to produce a value of the "feature option
object" type in a specific state, commit f6a3f6d8ad instead
set fontconfig_option = false (when it wasn't set to 'enabled', i.e. it
was either 'auto' or 'disabled') in an attempt to disable building the
subproject. However, a boolean value of false is equivalent to 'auto',
not to 'disabled'. This is documented at
https://mesonbuild.com/Build-options.html#features
So commit f6a3f6d8ad wanted to convert
'auto' to 'disabled', but instead effectively converted 'disabled' to
'auto', causing the Fontconfig subproject to be always built on Windows,
even when explicitly turned off with -D fontconfig=disabled.
A way to accomplish the original goal is available since Meson 0.59;
feature option objects gained the '.disable_auto_if()' method that
exactly converts 'auto' to 'disabled' if the boolean condition is true.
So make use of this method to properly turn off building Fontconfig on
Windows, unless explicitly enabled with -D fontconfig=enabled.
Apply the same for FreeType, which is also not very useful on Windows.
See also: 7f8135bfeb
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
When trying to build with -Dpng=disabled with a new enough FreeType
version, the build would fail in cairo-svg-glyph-renderer.c:
src/cairo-svg-glyph-render.c:1841:15: error: implicit declaration of
function ‘cairo_image_surface_create_from_png_stream’; did you mean
‘cairo_image_surface_create_for_data’?
[-Werror=implicit-function-declaration]
Fix this by disabling HAVE_FT_SVG_DOCUMENT when png is not enabled.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/784
Signed-off-by: Uli Schlachter <psychon@znc.in>
