[Fontconfig] Fontconfig 2.10.0 mingw build broken
Damon Register
dregister at clear.net
Mon Jul 23 16:03:34 PDT 2012
On 7/23/2012 1:32 PM, Akira TAGOH wrote:
> I don't see any error on Linux say... ln is capable to create a broken
> symlink (at that point) but it could be valid later.
Oh. I was not aware of that. Assuming then that the files in question
get put there later, then it would work, right? I think I might know then
why this doesn't work with mingw on Windows. As far as I know, when using
mingw/msys on windows, the ln can't create symbolic links since that
is something Windows doesn't understand. I believe that it just does a
copy instead which would mean that this anticipation type link won't work
because you can't copy a file that doesn't exist, right?
> Anyway, on git master, installing config files happens earlier than
> creating symlinks now. it should works for you. try it.
fascinating. I will try it.
> Yes. it's intentional, because those symlinks are referring from the
> installed config files. otherwise all of users has to install the
> source code too.
Ok, I think I understand all this. So, the question that remains is this:
how can the code be fixed so that those files exist before making a
symlink such that it won't break on Windows?
> Well, difference between 2.9 and 2.10 is whether the source place of
> ln is the relative path or the absolute path. no changes in the
but regardless of relative or absolute, if the source doesn't exist,
then a copy would break, right?
> installation order. so any config files shouldn't be there at that
> time. but your ln didn't just complain that for the relative path I
> guess.
I don't totally understand the differences between 2.9.0 and 2.10.0
but I do know that 2.9.0 installed without this problem. I know I could
be wrong but it seems to me that the order must have been different if
this worked on windows.
Damon Register
More information about the Fontconfig
mailing list