Try trivial program: #!/usr/bin/perl require 'sys/types.ph'; require 'sys/socket.ph'; It'll barf on you: "Can't locate stddef.ph in @INC (did you run h2ph?)" - this is while compiling 'sys/types.ph' !!! Reproducible: Always Steps to Reproduce: This is since it's in /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include , not in /usr/include. If you'll try to fix the problem with cd /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include ; h2ph *.h you'll get different error message: "Undefined subroutine &main::__LONG_MAX__ called at (eval 257) line 1". This somewhat cryptic error message comes from the fact that /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include/limits.h uses some internal gcc constants so it can be fixed with cd /usr/include ; h2ph limit.h (it's the only file on my system which can be found in both /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include and /usr/include). Am I asking too much when I want freshly installed perl compile trivial program with require 'sys/socket.ph' ? Some scripts are using it (I've stumpled upon it in apache2logserverstatus from apache2).
Hold your hats, but this will be fixed in a new -r of perl coming out in the next day. It will also be fixed in the next version of perl-cleaner to be posted at the same time. The crux of the matter is that we got a lot of flack for doing too much h2ph for the user, so we cut it down to a bare minumum. I've added back in /usr/include/gnu and /usr/include/linux which will take care of your problem. So, give me a day for a go ahead on posting the new ebuilds (related to a glsa, unrelated to this bug in every other way) and you will be all golden.
Emerge sync - fixed in perl ebuild, though I'd probably recommend just running "dev-lang/perl/files/perl-cleaner phall"
