GNU LilyPond 2.8.0 terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid Aborted (gdb) bt #8 0xb7bea28f in std::__throw_logic_error ( __s=0xb7c5ca08 "basic_string::_S_construct NULL not valid") at /usr/src/debug/sys-devel/gcc-4.1.1-r3/gcc-4.1.1/libstdc++-v3/src/functexcept.cc:63 #9 0xb7c2ff38 in std::string::_S_construct<char const*> (__beg=0x0, ---Type <return> to continue, or q <return> to quit--- __end=0xffffffff <Address 0xffffffff out of bounds>, __a=@0xbfcc3f5c) at /usr/src/debug/sys-devel/gcc-4.1.1-r3/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:145 #10 0xb7c30087 in basic_string (this=0xbfcc3f20, __s=0x0, __a=@0xbfcc3f5c) at /usr/src/debug/sys-devel/gcc-4.1.1-r3/build/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1449 #11 0x080b3869 in init_fontconfig () at font-config.cc:37 #12 0x08101d5e in main_with_guile () at main.cc:392 #13 0xb7f537fa in scm_boot_guile (argc=0, argv=0x0, main_func=0, closure=0x0) at init.c:635 #14 0x08100101 in main (argc=2, argv=0xbfcc4164) at main.cc:623 font-config.cc: FcChar8 *cache_file = FcConfigGetCache (font_config_global); /* This is a terrible kludge, but there is apparently no way for FontConfig to signal whether it needs to rescan directories. */ if (!is_file ((char*)cache_file)) message (_f ("Rebuilding FontConfig cache %s. this may take a while...", cache_file)); Since fontconfig 2.4, FcConfigGetCache() always returns NULL.
Hm, seems fixed in git: http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob;f=lily/font-config.cc;hb=32ffe890dfdc1009b1c31e201750221bfc8e7e35 I wonder whether it's been released?
Right, yeah, it's fixed in the latest stable (lilypond-2.10). Time to cc myself on bug 132706.
please use 2.10.23