I've just dealt with a user reporting this problem in Hardy i386. As soon as gdm tried to start gdmgreeter the log-in screen went 'mad' in his words. I connected remotely via ssh and stopped the gdm process. libcairo was reporting symbol_not_found for FT_Library_SetLcdFilter.
ldd /usr/lib/libcairo.so.2
revealed that it was linked against /usr/local/lib/libfreetype.so.6
I discovered that recently the user had been trying to build an application of some sort, which had included libfreetype2. When it had been built it had installed to /usr/local/lib/ and then ldconfig had regenerated the dynamic module cache and it took preference to the system-installed version in /usr/lib/.
The version in /usr/local/lib/ was much older than the version in /usr/lib/ and didn't include the FT_Library_SetLcdFilter() function.
The fix was to remove the libfreetype libraries and sym-links from /usr/local/lib/ and to regenerate the linker cache using:
I've just dealt with a user reporting this problem in Hardy i386. As soon as gdm tried to start gdmgreeter the log-in screen went 'mad' in his words. I connected remotely via ssh and stopped the gdm process. libcairo was reporting symbol_not_found for FT_Library_ SetLcdFilter.
ldd /usr/lib/ libcairo. so.2
revealed that it was linked against /usr/local/ lib/libfreetype .so.6
I discovered that recently the user had been trying to build an application of some sort, which had included libfreetype2. When it had been built it had installed to /usr/local/lib/ and then ldconfig had regenerated the dynamic module cache and it took preference to the system-installed version in /usr/lib/.
The version in /usr/local/lib/ was much older than the version in /usr/lib/ and didn't include the FT_Library_ SetLcdFilter( ) function.
The fix was to remove the libfreetype libraries and sym-links from /usr/local/lib/ and to regenerate the linker cache using:
sudo ldconfig