In my livecd-stage2 catalyst build for the x86 install CD, splashutils (both versions) fail to configure because it cannot find /lib/cpp. It cannot find /lib/cpp because it doesn't exist, because the toolchain in the chroot was built with USE=nocxx. The check is in the freetype folder, iirc. AFAIK, splashutils does not need a C++ compiler, so it doesn't make much sense for it to check for one.
Ok, it's not that /lib/cpp doesn't exists. It's that it's trying to use it to preprocess C++, which it apparently cannot do (because of USE=nocxx).
It looks like adding 'epunt_cxx' to the end of src_unpack() "fixes" this. Although, why is it still building freetype2 internally when freetype-2.1.9 is pulled in as a dep?
The "external" freetype (ie. the one that is pulled as a dep) is what splash_util/splash_util.static is linked to, whereas the "internal" freetype is built against klibc and is what splash_helper (the kernel helper) is linked to. It has to be done this way since we want to be able to put splash_helper into an initramfs image, where glibc is not available and using klibc is the only realistic option.
Fixed in CVS, thanks for the suggestion about 'epunt_cxx'.
