Description of problem: Apps segfault if $HOME isn't in the environment, because FcStrCopyFilename calls strlen() on the result of getenv() before checking it for NULL. # unset HOME ; /usr/bin/bluepin asd asd Segmentation fault Fixing the segfault with the (soon to be) attached patch is only vaguely helpful -- apps still fail to start... # unset HOME ; LD_LIBRARY_PATH=/usr/src/redhat/BUILD/fcpackage.2_1/fontconfig/src /usr/bin/bluepin asd asd No fonts found; this probably means that the fontconfig library is not correctly configured. You may need to edit the fonts.conf configuration file. More information about fontconfig can be found in the fontconfig(3) manual page and on http://fontconfig.org Setting HOME to a bogus nonexistent directory makes the application work fine; it's not that the directory is actually required.
Created attachment 91316 [details] partial fix
Just out of couriousity - and to know how important a "functional" fix is, when would programs be running without $HOME in the environment? Is this a situation when using getpwuid() would work?
Not sure how common it'll be -- the example is a GUI dialog box invoked from a deamon (it's in the bluez-utils package if you want to look closer) and is the WrongThing anyway -- dbus or whatever will obsolete it soon, hopefully. If it didn't work with 'HOME=/somebogusdir' and actually _needed_ the home directory, I'd suggest that it isn't worth fixing. But since it does work like that, it seems like it might be fairly simple to make it work with !HOME. I've worked around it in bluez-utils for now, just by setting HOME to "" in the bluepin script.
Fixed upstream as of 2003/02/06, tests OK with fontconfig-2.2.1-1