/sbin/splash-functions.sh contains: export spl_util="//bin/splash_util.static" However, the splash_util.static symlink is installed in /sbin. Not sure whether it's an ebuild or an upstream problem. I think it's best to fix splash-functions.sh. Reproducible: Always Steps to Reproduce:
Moreover, /sbin/splash-functions.sh has a bug. In splash_get_mode(), local ctty="${spl_bindir}/fgconsole" local mode="$(${spl_util})" should be: local ctty="$({spl_bindir}/fgconsole)" local mode="$(${spl_util} -c getmode)" This bug prevents "splash svc_input_begin/end" from working.
> local ctty="$({spl_bindir}/fgconsole)" Sorry, should be local ctty="$(${spl_bindir}/fgconsole)"
One more comment: > I think it's best to fix splash-functions.sh Apparently, splash-functions.sh is written in such way that // can be replaced with /usr/ to use dynamic executables instead of static. So it's probably best to relocate the splash_util.static symlink to /bin, to be compatible with /usr/bin/splash_util (or to do the reverse, relocate splash_util to /usr/sbin).
Thanks for spotting and reporting the bugs. I fixed these problems in the main splashutils repository and added appropriate patches to the Gentoo CVS.
Thanks for the fast response! I have just one more comment: fbcondecor_helper is supposed to be a "simple and small program run directly by the kernel", but it can actually grow quite large, due to static libjpeg + libpng + libfreetype + libmng compiled in. But does it have to be statically linked even once it is pulled from mounted fs (after initramfs is gone)? If not, two versions of fbcondecor_helper could be produced, just like with the other utilities, one with klibc + *.a inside, and another linked against libc + *.so. I also suggest making jpeg support optional, like png (I really like the idea of a small initramfs image. :))