your newer fontconfig version does not work properly in windows vista home premium. Some GIMP bug report numbers are e.g. Bug 390588, Bug 420660, Bug 429805, Bug 154968, Bug 473914 ..., with the actual open http://bugzilla.gnome.org/show_bug.cgi?id=378153. It is somewhat referred to as "the well known fontconfig issue". I have read about windows stat() implementation as possible reason for the bug. On my computer, the .dll from the gtk+-package 2.10.6 works, but slow at the first start, but the newer version from gtk+ 2.10.13 does not create a font cache at all.
This is a Vista-only bug, I think. It is due to this _closed_ (but not fixed) bug in at least mingw, where X_OK is badly defined in io.h. I have tried to report it to the mingw bugzilla: https://sourceforge.net/tracker/index.php?func=detail&aid=1593268&group_id=2435&atid=202435 Changing the header value of X_OK then rebuilding fixed the problem for me (I was affected by it with gimp, and also when running fc-cache directly).
Created attachment 11959 [details] [review] define X_OK to 0 on win32 This just defines X_OK to 0 on win32, which should fix the problem. I've not actually tested this though, so I'd appreciate if someone would. :)
I've tried to dig a bit further... Defining X_OK to 4 is a bad idea, as I found the following code: #ifdef __USE_MINGW_ACCESS /* Old versions of MSVCRT access() just ignored X_OK, while the version shipped with Vista, returns an error code. This will restore the old behaviour */ static inline int __mingw_access (const char* __fname, int __mode) { return _access (__fname, __mode & ~X_OK); } #define access(__f,__m) __mingw_access (__f, __m) #endif Unfortunately, a quick grep through mingw's header doesn't report a single place where this could be defined. I guess that the *real* fix would be to have this define set for a mingw target. But then again, this is something that could be by default, as X_OK is useless for access.
(In reply to comment #3) > I've tried to dig a bit further... Defining X_OK to 4 is a bad idea, as I found > the following code: > > #ifdef __USE_MINGW_ACCESS > /* Old versions of MSVCRT access() just ignored X_OK, while the version > shipped with Vista, returns an error code. This will restore the > old behaviour */ > static inline int __mingw_access (const char* __fname, int __mode) > { return _access (__fname, __mode & ~X_OK); } > #define access(__f,__m) __mingw_access (__f, __m) > #endif Note the patch I attached here makes X_OK == 0, instead of 4. 4 would be a bad idea for other reasons anyway. > Unfortunately, a quick grep through mingw's header doesn't report a single > place where this could be defined. I guess that the *real* fix would be to have > this define set for a mingw target. But then again, this is something that > could be by default, as X_OK is useless for access. > Could do that.. but then compiling against an older version of mingw would still result in problems. Perhaps a fontconfig maintainer could voice an opinion on a preferred approach?
What I meant is that the fix for vista implemented by mingw project doesn't look like it could cause a problem for older versions of Windows, which simply ignored this element that didn't make any more sense. Therefore, asking mingw maintainers if they could make the fix inconditionnal is a better idea: everybody, not only, fontconfig, gets fixed. Otherwise, fontconfig might just do what the fix does: #if defined(WIN32) && !defined(__USE_MINGW_ACCESS) # define access(__fname, __mode) _access (__fname, (__mode) & ~X_OK) #endif Which is more valid IMHO.
I've removed all uses of X_OK from fontconfig which should fix this bug.
*** Bug 11498 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.