[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