| Summary: | fontconfig creates no font cache, therefore making GIMP useless on vista | ||
|---|---|---|---|
| Product: | fontconfig | Reporter: | E. Cortez <drumkid> |
| Component: | fc-cache | Assignee: | Keith Packard <keithp> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | medium | CC: | christophe.gisquet, snarkotron, yosh |
| Version: | 2_1 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | define X_OK to 0 on win32 | ||
|
Description
E. Cortez
2007-09-15 20:20:16 UTC
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. |
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.