This was thanks to a report from crucible (run #2113) since it tested
with older versions of gcc (3.3.6) than most of the cairo developers
use, (so we had been getting the _FbOnes macro not the function).
(cherry picked from 82b710ebc2 commit)
This adds a win32 initialization function that is called from all
surface creation and font creation functions to ensure that the win32
mutexes are initialized.
(cherry picked from dbd0fa193c commit)
This is a little simpler than the old idiom of calling
_cairo_output_stream_get_status just before calling
_cairo_output_stream_destroy.
I had hoped this technique would apply in more cases, but
many cases want to separate the two actions anyway to do
conditional assignment of the status value, (in order to
not overwrite an earlier error value).
(cherry picked from 179f7defdf commit)
This doesn't actually fix the AMD64 link failure, but it does make the
foo/EXT_foo/INT_foo symbol names generated by the slim_hidden_proto()
and slim_hidden_def() macros consistent in the face of the meddling of
pixman-remap.h.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
(cherry picked from 203d70a562 commit)
In order for SLIM's PLT indirection avoidance to work, everything in
the library that makes internal function calls needs to see the
relevant slim_hidden_proto() macro in addition to the function's
prototype. However, external headers used by clients of the shared
library should not use the SLIM macros at all.
Pixman is a rather odd case -- it's mostly independent from cairo, so
it has it's own public interface, but it's built as a part of cairo
instead of its own shared library. This means that cairo would need to
see all of pixman's slim_hidden_proto() macros in order to function
and it doesn't currently, which results in a link failure on AMD64
systems and on i386 systems (I think, I haven't actually verified
this) it produces a shared object that isn't actally sharable.
I have no idea why exactly the link failure only showed up as a result
of commit e06246b9b1. I think it has
something to do with the pixman functions no longer having PLT entries
at all, but the exact interaction isn't clear to me.
However, all of these pixman functions aren't part of the cairo ABI
(which is why they were marked pixman_private in the first place),
which means that the SLIMification of pixman is largely pointless --
they aren't externally visible, so they don't need PLT entries at
all. Furthermore, while pixman may eventually be shared among cairo
and X, I'm told that this sharing will be source-level only, which
means it won't ever be an actual shared library and thus won't ever
need SLIM at all.
So, I just removed all use of SLIM in pixman (leaving behind
slim_internal.h for the future edification of anyone who cares).This
fixes the AMD64 link failure and passes the check-plt & check-def
parts of make check.
Signed-off-by: Nicholas Miell <nmiell@gmail.com>
(cherry picked from d598cd8d61 commit)
src/check-def.sh checks that the list of symbols exported is the same as the
list of symbols in cairo.def, ie. symbols in public header files. (except for
symbols starting with _cairo)
src/check-plt.sh checks that no PLT entries exist for local function calls.
This makes sure we keep the 'slim' annotations uptodate.
These two are defined as tests in src/ and will be run during "make distcheck".
However, they are skipped if the commands 'nm' and 'readelf' are not found.
(We don't really rely on any functionality of eu-readelf, so using readelf
proper which should be more commonlly installed.)
(cherry picked from cd1b665064 commit)
PDF Files with Type 1 fonts fail to open in any version of
ghostscript prior to 8.54. The problem is the hex encoding of the
encrypted portion of the font. The PDF reference says this should
only be in binary.
(cherry picked from d81de15804 commit)
Basically, it's evil to write a loop like:
while ((c -= 4) > 0) {
...
}
for one reason that doesn't work if c is unsigned. And when c is signed, if
for some reason c is about -MAXINT, then it will overflow and not work as
expected.
It's much safer (and more gcc warning friendly) to rewrite it as:
unsigned int c;
while (c >= 4) {
...
c -= 4;
}
Behdad chased this bug down when looking into bug #7593. This
bug is what finally motivated us to figure out how to get -Wextra
(for the "always true" comparisons of unsigned variables against
negative values).
We'd been wanting some of the warnings in -Wextra for a long time,
but we had failed in tryingto squelch some of the undesired warnings.
We finally figured out how to do this correctly by simply ordering
the warnings correctly.
The documentation for GetGlyphOutline() states that outline returned is grid
fitted and if an application requires an unmodified outline it can request an
outline for a font whose size is equal to the font's em unit.
This seems to suggest that the solution to this bug would be to obtain the
unmodified outline data and scale it to the required size.
https://bugs.freedesktop.org/show_bug.cgi?id=7603
