How about trying FC_DEBUG=16 fc-cache -s -f -v ?

(In reply to comment #1)
> How about trying FC_DEBUG=16 fc-cache -s -f -v ?

That didn't seem to have any effect:

/boot/develop/haikuports/media-libs/fontconfig> export FC_DEBUG=16
/boot/develop/haikuports/media-libs/fontconfig> fc-cache -s -f -v
FC_DEBUG=16
/boot/system/data/fonts: FcDirCacheWriteDir dir "/boot/system/data/fonts" file "/boot/home/config/cache/5157313ead2cc69f2f1facc820bc1c40-le32d4.cache-3"
caching, new cache contents: 0 fonts, 2 dirs
/boot/system/data/fonts: failed to write cache
/boot/system/data/fonts/psfonts: 
charsets 4 -> 1 leaves 32 -> 8
FcDirCacheWriteDir dir "/boot/system/data/fonts/psfonts" file "/boot/home/config/cache/769d9a69f673a14def07956f0d2b1eaf-le32d4.cache-3"
caching, new cache contents: 4 fonts, 0 dirs
/boot/system/data/fonts/psfonts: failed to write cache
/boot/system/data/fonts/ttfonts: 
charsets 23 -> 15 leaves 956 -> 261
FcDirCacheWriteDir dir "/boot/system/data/fonts/ttfonts" file "/boot/home/config/cache/31beb5587a82d4f166ba0188704169a3-le32d4.cache-3"
caching, new cache contents: 23 fonts, 0 dirs
/boot/system/data/fonts/ttfonts: failed to write cache
/boot/common/data/fonts: FcDirCacheWriteDir dir "/boot/common/data/fonts" file "/boot/home/config/cache/0b800401f4e3427d0ccea7c1305e4fa4-le32d4.cache-3"
caching, new cache contents: 0 fonts, 0 dirs
/boot/common/data/fonts: failed to write cache
/boot/home/config/data/fonts: FcDirCacheWriteDir dir "/boot/home/config/data/fonts" file "/boot/home/config/cache/02d9b1b5d93daf7b915936a5e9d302f4-le32d4.cache-3"
caching, new cache contents: 0 fonts, 0 dirs
/boot/home/config/data/fonts: failed to write cache
/boot/home/config/cache: cleaning cache directory
fc-cache: failed
/boot/develop/haikuports/media-libs/fontconfig>

Thanks. attaching the log of strace too would be appreciated.

Any comments?

Are you sure you have the certain privileges to access those directories?

Are you setting cachedir to any FAT filesystem perhaps?

Try git master. it might help.

Haiku use OpenBFS for the file system by default.  OpenBFS like BFS for BeOS does/did not support hard linking, perhaps that is the issue here?  An example patch for dealing with this has been posted to HaikuPorts but we have not yet verified that it fixes the issue.
http://ports.haiku-files.org/attachment/ticket/261/fontconfig-2.8.0.patch
You can see the text version of the patch by clicking on the 'original format' link at the bottom of that page.  This didn't look like a very clean way of fixing it to me.  Perhaps you know of a cleaner fix?  OpenBFS does support symlinks, so perhaps those could be used as a fallback fix?
Haiku defines __HAIKU__ so if you need to use ifdefs you could use that.  Perhaps a better fix would be to check for hard link capability in configure and then take action based on that result.

Also the fix for fontconfig ticket #26157 breaks the build for Haiku, at least for building with gcc2.95.3, which we use for maintaining backward compatibility with BeOS.
http://cgit.freedesktop.org/fontconfig/commit/src/fcint.h?id=3cd1e673a9b518784183029d5cc1d2adae0cb29a
changing it from end[] back to end[0] then allows fontconfig-2.9.91 to compile on Haiku, but we still get the same unable to write cache file errors as with 2.8.0.
The reported failure is: fcint.h:281 field `end' has incomplete type
-scottmc

Thanks for updating. I'll have a look at it then.

Please try to checkout:

$ git clone git://people.freedesktop.org/~tagoh/fontconfig bz30077

If the above things are subject, that tree should works.

Using bz30077 did the same as before.  Here is the build steps I used:
FONTS_DIR=`finddir B_SYSTEM_FONTS_DIRECTORY`
FONTS_DIR2=`finddir B_COMMON_FONTS_DIRECTORY`
FONTS_DIR3=`finddir B_BEOS_FONTS_DIRECTORY`
FONTS_DIR4=`finddir B_USER_FONTS_DIRECTORY`
CACHE_DIR=`finddir B_USER_CACHE_DIRECTORY`
DOCS_DIR=`finddir B_COMMON_DOCUMENTATION_DIRECTORY`
DATA_DIR=`finddir B_COMMON_DATA_DIRECTORY`

./autogen.sh --prefix=`finddir B_COMMON_DIRECTORY` --enable-libxml2 --with-default-fonts=${FONTS_DIR} \
--with-add-fonts=${FONTS_DIR2},${FONTS_DIR3},${FONTS_DIR4} \
--with-cache-dir=${CACHE_DIR} --mandir=${MAN_DIR}/man \
--docdir=${DOCS_DIR}/doc       --datarootdir=${DATA_DIR}

make
make install

Haiku has a command line utility "finddir" which will return the directory name for several of it's standard directories, use finddir -l to see a list of all of the constants it will find locations for.  These will probably change in the next year or so, so we don't want to hard code them in our build scripts.

If you'd like to test it out yourself you can find recent Haiku VM images here:
http://www.haiku-files.org/unsupported-builds/x86-gcc2/
Git isn't installed by default, but you can have it installed by using the command line program "installoptionalpackage" by typing "installoptionalpackage git".  The VM images are small, but might be large enough to test build fontconfig.  The terminal is located off the "blue leaf" button, then applications/terminal.  It is bash 4.x based.
Maybe you'll spot something I'm overlooking...

--mandir=${MAN_DIR}/man should be --mandir=${DOCS_DIR}/man

I think you mentioned two issues at Comment#7. one is the build issue that is related to the variable-length-arrays. one is the hard link issue.

For former issue, that tree is checking in configure if the compiler is capable to deal with the VLA. if this doesn't work, it may be better filing a bug to autoconf for that.

For later issue, if link() failed, it tries to fallback another method for atomic lock. so if you can still see this issue, that may means the root cause may be different or there may be multiple issues to get it working on Haiku then.

(In reply to comment #9)
> Please try to checkout:
> 
> $ git clone git://people.freedesktop.org/~tagoh/fontconfig bz30077
> 
> If the above things are subject, that tree should works.

Hm, doh, it should be:

git clone -b bz3077 ...

BTW I've tried to build it on Haiku as you introduced the above, apparently there are no pkg-config installed and installoptionalpackage pkg-config nor pkgconfig didn't help.

Hm, wrong autoconf macro. try again with the updated tree.

$ git clone -b bz30077 git://people.freedesktop.org/~tagoh/fontconfig fontconfig-bz30077

I've updated the .bep file and added a patch on haikuports to get 30077 building and working on both gcc2h and gcc4h.

TAGOH-san, apparently you need to install both pkgconfig and freetype from haikuports before compiling fontconfig.

http://ports.haiku-files.org/ticket/606

I laid out the steps there.

Were you saying in your last comments that fontconfig should be able to detect whether or not linking works and compile correctly without the patch?

It still didn't work for me, but with the patch it works fine.

(In reply to comment #15)
> TAGOH-san, apparently you need to install both pkgconfig and freetype from
> haikuports before compiling fontconfig.
> 
> http://ports.haiku-files.org/ticket/606
> 
> I laid out the steps there.

Yes, thanks. I missed the step to install haikuporter that is described at the top page ;)

> Were you saying in your last comments that fontconfig should be able to detect
> whether or not linking works and compile correctly without the patch?

As I said in comment#12, you have two issues. one is OpenBFS doesn't support the hard-linking as it also described in comment#7. this issue has been fixed/improved in git master already. one is the build issue with gcc-2.95. bz30077 branch in my tree has this fix with the common way.

HOWEVER, okay, I've tracked down. indeed the root cause is came from link(). how come link() in Haiku returns the own error code but not POSIX one? EPERM should be the appropriate error in this case rather than own error code, B_UNSUPPORTED.
That looks to me like a bug in Haiku.

Once it get fixed in Haiku, it should works.

All of _necessary fixes_ is in git master now. incompatibility of link() isn't OURBUG. so I'm afraid I don't have any plans to add a fix for that in fontconfig. for your workaround until it get fixed in Haiku, this patch would works:

diff --git a/src/fcatomic.c b/src/fcatomic.c
index 350744a..8f4641e 100644
--- a/src/fcatomic.c
+++ b/src/fcatomic.c
@@ -132,7 +132,7 @@ FcAtomicLock (FcAtomic *atomic)
        return FcFalse;
     }
     ret = link ((char *) atomic->tmp, (char *) atomic->lck);
-    if (ret < 0 && errno == EPERM)
+    if (ret < 0 && (errno == EPERM || errno == B_UNSUPPORTED))
     {
        /* the filesystem where atomic->lck points to may not supports
         * the hard link. so better try to fallback