I just switched to use Linux at work. I’ve had Gentoo at home for years but Windows seems to be a part of the consulting branch of work I’ve done so far.
The new machine I got was of course a 64 bit one and I installed the right distribution. After a week of use I sadly set my use flags a bit wrong so a emerge –depclean removed a bunch of packages in use and kdelibs was one of them.
Because I had to do actual work, and the things requiring kdelibs where mainly chat and convenience features, it took me almost a week to find a solution.
The failure was hidden in the make scripts. The CMakefile failed on row 146. It compiles support widgets using a make script called Makefile2. After I ran the script manually I found that it failed on the /usr/lib64/libz.so.1 not being a valid ELF binary.
I can understand that it didn’t work when the file /usr/lib64/libz.so was a text file talking about linking in /lib64/libz.so.1.2.8 by scripting.
/* GNU ld script Since Gentoo has critical dynamic libraries in /lib, and the static versions in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we run into linking problems. This "fake" dynamic lib is a linker script that redirects the linker to the real lib. And yes, this works in the cross- compiling scenario as the sysroot-ed linker will prepend the real path. See bug http://bugs.gentoo.org/4411 for more info. */ OUTPUT_FORMAT ( elf64-x86-64 ) GROUP ( /lib64/libz.so.1 )
The reasoning for making this file a script is explained in http://bugs.gentoo.org/4411 is due to dynamic linking making files larger. In my case this wasn’t an issue because the kdelibs could be as large as they want to as long as they compile.