This changes the rewriting of the FC_FILE values for relocated caches to an earlier stage
while reading the cache. This is better, because it means all APIs will report the
rewritten paths, not just the once that use the list apis.
We do this by detecting the relocated case and duplicating the FcPattern and FcPatternElm
in an cache allocation (which will die with the cache) and then reusing the FcValueLists
from the cache.
This means that in the rewritten case we will use some more memory, but not the full
size of the cache. In a test here I had 800k of relocated caches, but ~200k of wasted
on duplicating the objects.
This should fix https://bugs.freedesktop.org/show_bug.cgi?id=106618
Whilst working on the Reproducible Builds[0] effort, we noticed that
fontconfig generates unreproducible cache files.
This is due to fc-cache uses the modification timestamps of each
directory in the "checksum" and "checksum_nano" members of the _FcCache
struct. This is so that it can identify which cache files are valid
and/or require regeneration.
This patch changes the behaviour of the checksum calculations to prefer
the value of the SOURCE_DATE_EPOCH[1] environment variable over the
directory's own mtime. This variable can then be exported by build
systems to ensure reproducible output.
If SOURCE_DATE_EPOCH is not set or is newer than the mtime of the
directory, the existing behaviour is unchanged.
This work was sponsored by Tails[2].
[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/specs/source-date-epoch/
[2] https://tails.boum.org/
realfilename is the file name after sysroot adjustments. It should be used
instead of filename in the call to FcOpen() which forwards the name directly to
open().
Though I don't explicitly request a sysroot, I was getting error messages saying
"failed reading config file". This CL fixes the error spam.
The expression "1 << 31" will cause UBSAN to complain with this error message:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
The same operation on unsigned types is fine, however. This CL replaces the
strings "1 <<" with "1U <<".
In 161c738 I switched from linear name scanning to binary searching.
That, however, ignored the fact that there might be more than one
name table entry for each pair we want to query.
To fix that and retain bsearch, I now get all name entries first,
sort them, and use for bsearching.
This fixes https://bugs.freedesktop.org/show_bug.cgi?id=105756
This makes scaning Voto Serif GX twice slower though, since we are
creating and sorting the list for each instance. In the next commit,
I'll share this list across different instances to fix this.
We were comparing the passed in key with the ready-to-insert key
rather than the key in the hashtable, so if you ever had a hash
conflicts we'll never insert the new item.
https://bugs.freedesktop.org/show_bug.cgi?id=101889
Akira TAGOH
Alexander Larsson
Chris Lamb
Tom Anderson
Behdad Esfahbod
Olivier Crête