GCC 12.2 reports the following warning:
[3/16] Compiling C object util/cairo-script/libcairo-script-interpreter.so.2.11801.1.p/cairo-script-scanner.c.o
../util/cairo-script/cairo-script-scanner.c:1562:38: warning: implicit conversion from 'int' to 'float' changes value from 2147483647 to 2147483648 [-Wimplicit-const-int-float-conversion]
if (real >= INT32_MIN && real <= INT32_MAX && (int) real == real)
~~ ^~~~~~~~~
/usr/include/stdint.h:123:22: note: expanded from macro 'INT32_MAX'
^~~~~~~~~~
I tried to use cairo-sphinx do to something useful. I failed.
The cairo-sphinx binary was added in commit 6e0b3be903 in 2009 by ickle
with the explanation:
Add cairo-sphinx utility for regression analysis
sphinx is an alternate version of the current cairo-test-trace. It's
purpose is to replay a live application (which may just be a replay of a
trace) against a backend and its reference. The improvement over the
original cairo-test-trace is that the reference backend may be from an
older version of cairo.
Ever since this commit, there were only build fixes to this code (for
example to fix compilation on AIX or to fix compilation after
cairo-tee.h became optional). So, either this code was perfect from the
beginning or it was not much used.
Next, I tried to reverse-engineer a bit how to actually use this. The
non-existing documentation didn't help much. The result? Well...
something happened, but I am not quite sure what. Then the server
process just exited.
So, in this commit I am removing cairo-sphinx. The hope is that someone
speaks up and complains. That person then hopefully can provide some
explanation on how to use this. Alternatively, no one speaks up and we
no longer have to maintain this piece of code.
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.
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
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 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.
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.
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
