<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - Pathnames mangled under windows" href="https://bugs.freedesktop.org/show_bug.cgi?id=74559#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - Pathnames mangled under windows" href="https://bugs.freedesktop.org/show_bug.cgi?id=74559">bug 74559</a> from <a class="email" href="mailto:akira@tagoh.org" title="Akira TAGOH <akira@tagoh.org>"> Akira TAGOH</a> <pre>(In reply to <a href="show_bug.cgi?id=74559#c4">comment #4</a>) > In this scenario, I am not cross compiling. I am explicitly building on > mingw for mingw. This is distinct to building with a microsoft compiler on > windows for windows. With a different bunch of environment variables in this > same setup I also cross compile from mingw targeting powerpc-ibm-aix5.1.0.0. > I guess that specifying the build value is kindof redundant as autoconf > should guess it correctly, however I need to set the host value so that it > is the correct answer for this compile stream as opposed to the cross > compile setting. I guess I could as well just unset the host-alias value > when targeting a local build - but I figured better to be explicit rather > than leave things to chance. I see. > Having said all that I still am unable to run the simple "basic check" that > is inside of test/run-test.sh under msys. With a lot of fiddling inside of > the fonts.conf, and setting the FONTCONFIG_FILE to a > C:\msys\home\dirk\myBuild\test this does work from a windows command prompt. > But the point is I am building the fontconfig library under msys using a > standard c library, and intend to link to it from programs in msys, so the > library build is effectivly broken as (in my opinion) a result of path > mangeling. What I am seeing is that any application trying to use fontconfig > on windows would have to also jump through all the path translation stuff > that is built into fontconfig to specify which config file to use, and where > the cache is and etc. Ah, okay. got it. well, I don't think test/run-test.sh does take care of win32 platform and apparently not. and no one complained about it ever. So that could be indeed improved. > Note that in my experience, any c library, be it gnu-linux, windows or > whatever is happy with paths expressed as /adir/asubdir, so all of the > string replace of '/' to '\\' when _WIN32 is defined is not necessary, and > in this instance is breaking the functionality of the library under msys. > Even with a native microsoft compiler, standard c functions like stat(), > mkdir() and etc. will use paths expresed as /x/y/x and do not need the > translation to c:\x\y\z. It is only when one starts to use actual windows > api's like GetModuleFileName() that the world becomes complicated with > microsoft "\" notation. In this case I am using gcc to compile, so the > implication is that I have a standard c library that is mostly > POISIX/GNU/C99 compliant. AFAIK win32 support has been improved with contributions from win32 developers. if you aren't comfortable with it on msys, any improvements are always welcome. please make sure in advance you don't make any regressions with it. > Has anyone had success with compiling and using fontconfig on cygwin? I > think that cygwin environment does its own path mangeling, so I dunno how > that will co-exist with fontconfigs efforts. I see 2.10.93 in their builds at least and I don't think we've drastically changed for win32 since then.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>