They don't support C11 anyway. Additionally, CLang defines a very
conservative __GNUC__ value (which is also configurable via the
-fgnuc-version= command-line argument)
This partially reverts commit ba4d5fbd5 from MR !343 which asked for
hidden symbols everywhere. cairo-fdr and cairo-trace explicitly try to
interpose existing symbols. Changing them to hidden symbols breaks these
tools.
See: https://gitlab.freedesktop.org/cairo/cairo/-/issues/882#note_2759005
Signed-off-by: Uli Schlachter <psychon@znc.in>
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 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.
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
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.
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
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>
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>
IGT wants to add support for planes with a bit depth >10, which
requires a higher precision format than we have currently.
I'm using RGBA as format, because of its existence in OpenGL.
With the new formats we can directly convert our bytes to half float,
or multiply a colro vector with a matrix to go to the Y'CbCr colorspace.
This requires pixman 0.36.0, so bump the version requirement.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
All the cases are the same, except len is different.
Use the already calculated len parameter to handle all
cases except RGB24 the same.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Suggested-by: Bryce Harrington <bryce@bryceharrington.org>
Reviewed-by: Bryce Harrington <bryce@bryceharrington.org>
Run the command below suggested by geirha in ##sed@irc.freenode.net.
git grep -l 'http://.*gnome.org' | xargs sed -i 's|http\(://\([[:alnum:].-]*\.\)\{0,1\}gnome\.org\)|https\1|g'
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
If the bitmap's min is non-zero, _bitmap_next_id() could break out of
its loop early, before initializing the prev variable. prev would then
be dereferenced without a null ptr check. This condition should never
occur in practice, so add an assert() to assure it doesn't.
Same issue is present in trace.c.
Coverity IDs: #1159557, #1159558
Reviewed-By: Uli Schlachter <psychon@znc.in>
Signed-off-by: Bryce Harrington <bryce@bryceharrington.org>
The current code results in trace lines with the source surface being
pushed on the stack two times instead of one:
s1 s1 //ARGB32 48 48 similar-image % s2
Instead of:
s1 //ARGB32 48 48 similar-image % s2
This greatly confuses later commands when the script was replayed,
causing traces for trivial GTK3 programs to be unplayable, usually
yielding the following error:
"invalid value (typically too big) for the size of the input (surface, pattern, etc.)"
Drop the duplicated entry from the trace line printed by the
cairo_surface_create_similar_image() override.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73580
Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>
There are many more that can go, but these take the most bytes.
FC_CHARSET needs to go specially because I recently changed
its format in fontconfig. Ouch!
ARRAY_LENGTH macro is used in perf's cairo-perf.h, src's cairoint.h,
test's cairo-test.h and in some internal header files of util's
directory.So to maintain consistency ARRAY_SIZE is replaced with
ARRAY_LENGTH macro.
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
This error enum was added last September when JBIG2 support was added.
Support it as well in the tracing code. This fixes this warning:
trace.c:1544:5: warning: enumeration value
‘CAIRO_STATUS_JBIG2_GLOBAL_MISSING’ not handled in switch [-Wswitch]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Recent updates (in the past couple of years) to firefox have exposed
numerous bugs in the way we emit the operands. A few off-by-ones,
missing surfaces and outright bugs all of which are intermixed into
producing a corrupt stack.
Reported-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In particular fixing up a couple of corner cases in emitting the right
instructions for scaled-fonts and patterns.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adjust the stack manipulation to avoid moving an unknown surface to
the dictionary.
Reported-by: Dongyeon Kim <dy5.kim@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just emit a marker for when cairo_image_surface_get_data() is called on
a surface so that we have a breadcrumb for when the pixels are first
exported. (Though note that pointer may be kept around and used much
later.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As discussed, overloading the cairo_surface_t semantics to include
sources (i.e. read-only surfaces) was duplicating the definition of
cairo_pattern_t. So rather than introduce a new surface type with
pattern semantics, start along the thorny road of extensible pattern
types.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
