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.
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>
This wasn't previously marked as private because it was initially
static inline, and only became extern later.
Fixes: 9ffbf63d "fix warning: inlining failed in call to '_csi_stack_push'"
Resolves: https://gitlab.freedesktop.org/cairo/cairo/-/issues/580
Signed-off-by: Simon McVittie <smcv@debian.org>
In !309 Taylor R Campbell found a number of instances of ctype
incorrectly passed a signed char. In many cases, where only ASCII
characters are used, the code should have been using the cairo version
of the ctype function to avoid locale issues.
The FT change is because my MinGW build is using a more recent version
of FT.
Remove the disabled _cairo_win32_scaled_font_text_to_glyphs() code to
fix the defined but not used warning.
_cairo_win32_scaled_font_text_to_glyphs() was diabled in d9408041aa with
the comment:
"Currently disable the win32-font text_to_glyphs(), until that one
is updated. Or better yet, remove it and implement
ucs4_to_index(). It's the toy font API afterall."
_cairo_win32_scaled_font_ucs4_to_index() was added in d1c619bc7d.
On 64-bit windows, long is 32-bit. When compiling there are a large
number of warnings about mismatched sizes when casting long to/from a
pointer.
Use the (u)intptr_t type for any integer that will have a pointer stored
in it. Use a (u)intptr_t cast when integers are stored in pointers to
silence warnings.
Fixes#263
Trying to build with meson with -Dzlib=disabled failed with the
following error message:
cairo/test/meson.build:599:2: ERROR: Unknown variable
"libcairoscript_dep".
This commit fixes that problem by adding a not-found dependency if
cairo-script is not built.
Additionally, follow-up problems are fixed:
- any2ppm.c still tried to include cairo-script-interpreter.h, which was
not found
- Building cairo-test-trace was attempted, but that also failed because
of missing script support.
Fixes: https://gitlab.freedesktop.org/cairo/cairo/-/issues/475
Signed-off-by: Uli Schlachter <psychon@znc.in>
For example, to depend on cairo-script, inccairoscript was added to
"include_directories:" and libcairoscript was added to "link_with:".
This commit instead uses the libcairoscript_dep dependency everywhere.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We *always* generate this file, and we depend on its existence.
The idea behind HAVE_CONFIG_H was being able to include random files
from different projects, back in a time where "libraries" were literally
just random files instead of actual shared objects.
Since we're not in the '80s any more, and our build system(s) define
HAVE_CONFIG_H *and* generate the config.h header file, we don't need a
conditional guard around its inclusion.
We define _GNU_SOURCE globally in both the Autotools build, through the
use of the AC_USE_SYSTEM_EXTENSIONS macro; and in the Meson build, with
add_project_arguments().
Precisely what Autotools does, instead of adding it as per-target C
argument.
Once we remove HAVE_CONFIG_H checks in every source file, we'll be able
to drop it.
The g_memdup() function has been deprecated, as it takes the size of the
memory area as an unsigned integer. The g_memdup2() replacement uses the
more appropriate size_t type, instead.
Install with exec flag set and make sure tool is
executable in build directory as well (by making
the input file in the source directory executable).
Fixes#462
Doesn't build any more, is very much non-essential, and hasn't
been touched in any meaningful way since it was added 13 years
ago, so just remove it for now until someone steps up. Chances
are the glibc version has improved since then.
And update configure/meson checks to check for the new function.
Drop libiberty.h check since it's only needed by backtrace-symbols.c
which we're about to remove.
Closes#391, #460
This fixes a typo wherein both a return character and a tab character
were encoded when only a return character was specified for encoding.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
trace-to-xml.c needs cairo-xml.h which is only available when
CAIRO_HAS_XML_SURFACE feature is built which is only available when both
zlib and png are found. CAIRO_HAS_INTERPRETER only requires zlib.
Including sys/poll.h when poll.h is available produces a compile
warning on some systems, but only sys/poll.h is present on others
such as AIX. This makes sure the most suitable poll.h is included
in each situation.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
This constitutes few fixes that are necessary to compile correctly
and reduce errors when using musl libc.
Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org>
