Subject: fc-cache problem with src/x11 build - reading host /etc/fonts?
To: None <current-users@netbsd.org>
From: Greg Troxel <gdt@ir.bbn.com>
List: current-users
Date: 06/29/2004 09:57:51
I am both building and running netbsd-2-0 from last week on i386.

Passing -x to build.sh usually works (if /usr/xsrc is free of crud
from previous non-build.sh builds), but I have run into situations
where fc-cache fails during the build.  In those cases, running it by
hand (using the tooldir version) seems to succeed, and then future
builds are ok.

Here is the output from a successful run.  Note the complain about the
config file, but /usr/obj/sinew/gdt/destdir/i386/etc/fonts is
populated, and has a timestamp earlier than the resulting cache files.

#    create  /usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/fonts.cache-1
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache -fv /usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts
Fontconfig error: Cannot load default config file
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts": caching, 0 fonts, 11 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/100dpi": caching, 358 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/75dpi": caching, 349 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/CID": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/Speedo": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/TTF": caching, 22 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/Type1": caching, 29 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/cyrillic": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/encodings": caching, 0 fonts, 1 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/encodings/large": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/local": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/misc": caching, 50 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: "/usr/obj/sinew/gdt/destdir/i386/usr/X11R6/lib/X11/fonts/util": caching, 0 fonts, 0 dirs
/usr/obj/sinew/gdt/i386/x11/tools/fc-cache/fc-cache: succeeded

When I ran that command by hand following a build failure, I ktrace'd
it and noticed that it read /etc/fonts/fonts.conf.  This seems wrong,
as that's a host file, not a target or tools file.  From skimming the
fc-cache sources, it looks like various failures cause the return
value to be incremented, but allow fc-cache to continue running.  So,
it may be that the command succeeds, but that the build fails due to
non-zero exit status.

Perhaps fc-cache needs a command line argument to pass a config
directory (or destdir?) and not look in the host locations.

A related question is that in debugging this, I rm -rf'd /usr/X11R6,
everything in /usr/obj (toolsdir, objdir, destdir, releasedir), and
/etc/fonts, in order to get an isolated build.  That worked, but the
contents of the xetc set didn't get installed by build.sh install=/.
I know one can hand-install the etc set by 'make install-etc-files' in
src/etc, but I can't see any way to install just the x etc files,
other than making a release and untarring the xetc set.  Also, I think
one can install all of X by doing "nbmake-i386 DESTDIR=/ install" in
src/x11, but that's a bigger hammer - which is arguably ok to use so
maybe that's the answer.

-- 
        Greg Troxel <gdt@ir.bbn.com>