We now require at least Windows Vista. When dwrite is disabled, declare
WINVER accordingly so we get the defines we no longer carry ourselves.
The default dwrite-enabled path already has a new-enough WINVER.
Fixes: d0ee67a142 ("Win32: Remove unused code and defines for old toolchains")
This happens when converting _cairo_status to _cairo_int_status:
warning C5286: implicit conversion from enum type '_cairo_int_status' to
enum type '_cairo_status'; use an explicit cast to silence this warning
Adds include of <termios.h> if system has it, in order to fix:
../perf/cairo-perf-print.c: In function ‘report_print’:
../perf/cairo-perf-print.c:62:28: error: storage size of ‘ws’ isn’t known
62 | struct winsize ws;
| ^~
../perf/cairo-perf-print.c:64:26: error: ‘TIOCGWINSZ’ undeclared
(first use in this function)
64 | if(ioctl(fd, TIOCGWINSZ, &ws) == 0 ) {
| ^~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
We only build C++ code for the host. Fixes Meson warning:
meson.build:486: WARNING: add_languages is missing native:, assuming languages are wanted for both host and build.
Pixman 0.42.3 added PIXMAN_r8g8b8_sRGB to pixman_format_code_t. CI
fails if it is missing from switch statements. Building with pixman <
0.42.3 will fail if the enum is used. So put it in a versioned #if.
Solaris defines alloca in the <alloca.h> header
../src/cairo-colr-glyph-render.c: In function ‘add_sweep_gradient_patches’:
../src/cairo-colr-glyph-render.c:661:14: error: implicit declaration of
function ‘alloca’ [-Werror=implicit-function-declaration]
661 | angles = alloca (sizeof (double) * cl->n_stops);
| ^~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
../../br-test-pkg/bootlin-armv5-uclibc/build/cairo-1.17.4/meson.build:279:13:
ERROR: Can not run test applications in this cross environment.
Commit 1bec56ea8a added support to define
ipc_rmid_deferred_release in a cross-compile config, but still kept
the default to auto, which anyhow results in an error when cross-compiling.
There is only one usage of the ipc_rmid_deferred_release compile declarative
which was originally added in this commit: 5041b462d0.
If ipc_rmid_deferred_release is set to FALSE, an additional XSync is performed.
This doesn't sound very harmful, so that is why this commit defaults to FALSE
and thus avoids any cross-compile errors.
Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com>
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.
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>
The DWRITE_COLOR_GLYPH_RUN1 struct definition of the old MinGW
dwrite_3.h was invalid. To work around the problem, dw-extra.h defined
the correct struct definition and all necessary API from dwrite_3.h.
This approach needed to redefine all necessary API.
This change added DWRITE_COLOR_GLYPH_RUN1_WORKAROUND struct and use it
for IDWriteColorGlyphRunEnumerator1::GetCurrentRun.
Now that FreeType 2.13.0 has been released with a stable COLRv1 API,
the meson configuration can be updated to enable COLRv1 when this
version is available.
According to the Debian code search tool, nothing uses it as part of the
Cairo public API, and it has been disabled for a long time with nobody
complaining about it.
The GL support in Cairo has always been a prototype, and
nothing happened in the past 10+ years to make it work as
it was meant to.
GL support is not enabled by any downstream packagers of
Cairo, so nobody should notice its absence.
WINVER and _WIN32_WINNT macros were defined in each source files and
headers that were including <windows.h>. However, because DirectWrite
requires new Windows API, some files included <windows.h> without the
version macros. This inconsistency sometimes caused troubles.
Define the version macros in meson.build.
It's not needed anymore.
Linking explicitly with libssp was required for toolchains where the
target libc doesn't implement stack smashing protection routines on
its own, and instead delegates to the generic implementations provided
by libssp. Notably, this was the case of mingw-w64 toolchains.
After discussion upstream with Meson developers [1], the stance taken
is that Meson users (and Meson itself) shall have no knowledge of the
libc internals and whether libssp is required. instead, libc's should
declare a dependency on the generic libssp on their own by means of
.spec files [2].
Following the discussion in Meson Github, the issue was then fixed in
mingw-w64 upstream [3].
References:
* https://github.com/mesonbuild/meson/issues/10673
* https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
* https://github.com/msys2/MINGW-packages/issues/13401
The rest of cairo (and therefore most external packages that depend
on cairo) doesn't make any use of liblzo.
Signed-off-by: Simon McVittie <smcv@debian.org>
