[Fontconfig-bugs] [Bug 74559] New: Pathnames mangled under windows

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=74559

          Priority: medium
            Bug ID: 74559
          Assignee: fontconfig-bugs at lists.freedesktop.org
           Summary: Pathnames mangled under windows
        QA Contact: freedesktop at behdad.org
          Severity: normal
    Classification: Unclassified
                OS: Windows (All)
          Reporter: tomsies at mighty.co.za
          Hardware: x86 (IA32)
            Status: NEW
           Version: unspecified
         Component: library
           Product: fontconfig

I have compiled fontconfig as a static library (not a dll) on Windows (Windows
7) using Mingw64 under MSYS. 

The issue I am facing is that all the path names inside of fontconfig are being
mangled from the provided /dir/subdir/fonts to c:\msys\dir\subdir\fonts. For
example in the test folder of the source tree I see fonts.conf.in
<fontconfig>
<dir>@FONTDIR@</dir>
<cachedir>@CACHEDIR@</cachedir>
</fontconfig>
which translates (under MSYS) to the correct answer of 
<fontconfig>
<dir>/home/dirk/mybuild/test/fonts</dir>
<cachedir>/home/dirk/mybuild/test/cache.dir</cachedir>
</fontconfig>

However if I now run fc-list, fc-cat or whatever either in a Windows command
prompt, or in the MSYS shell I get no output. If I change the <dir> tag to 
<dir>c:\msys\home\dirk\mybuild\test\fonts</dir>, I get output when running on
windows command prompt. No matter what combination of stuff I put in fonts.conf
execution in the MSYS shell fails. Note that the environment variable
FONTCONFIG_FILE is being correctly treated as a unix path under MSYS, and a
windows path under windows command prompt (i.e. I don't get "Fontconfig error:
Cannot load default config file" when these are set appropriately). However
from there on the path mangeling takes effect on the paths and files defined in
the fonts.conf. Note, I don't know if the package is not reading the fonts.conf
under MSYS (after checking for its existence), or if the file is being parsed
and the file / path names are getting messed up after they are read.

On inspection I see that there is a bunch of code in fontconfig (copied from
fccfg.c) that does:
#ifdef _WIN32
    {
        char *p;
        if(!GetModuleFileName(NULL, (LPCH) fontconfig_path,
sizeof(fontconfig_path))) ........
#endif

This test (_WIN32) does not take account of whether the library is compiled as
a dll (shared) or not. I have not checked the windows API to see if it returns
a path when invoked from a static library, but documentation indicates that it
will.
The test also does not care that the execution environment is unix like (MSYS,
CygWin) or Windows. I haven't looked at this under CygWin and cannot comment if
the same issue applies, but I assume it will. 

In all events a path returned by the windows GetModuleFileName API is not going
to work with unix like paths used in standard c. With a test like this at
compile time, perhaps a better test would be 
#if defined (_WIN32) && defined (_MSCVER)
on the assumption that if microsofts compiler is involved then the target is
vanilla windows? Or otherwise a test for _POSIX to see if standard path
resolution can be done?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/fontconfig-bugs/attachments/20140205/a67460d2/attachment.html>