OK, sys-libs/glibc will fail with an error if perl is missing from the system. <tgall_foo> greets <tgall_foo> helping rangerpb out there on a build <rangerpb> heya tgall_foo <tgall_foo> so glibc 2.6.1 is failing fairly late in the build .. it's trying to run a perl script <tgall_foo> perl's not there <tgall_foo> no gen-translit.pl < C-translit.h.in > C-translit.h.tmp <tgall_foo> so what's hapepning is .. there's a ./configure test for perl <tgall_foo> it's not found .... so <tgall_foo> no get's inserted as if it's the command ... <rangerpb> tgall_foo, what does configure look for wrt perl, can we see if that look was valid? <tgall_foo> configure:4800: checking for perl <tgall_foo> configure:4831: result: no <tgall_foo> that's from the config.log <tgall_foo> that perl script is during locale generation <tgall_foo> or rather it's in the locale directory <tgall_foo> in the makefile .. in locale: <tgall_foo> C-translit.h: C-translit.h.in gen-translit.pl <tgall_foo> $(PERL) gen-translit.pl < $< > $@.tmp <tgall_foo> mv -f $@.tmp $@ <tgall_foo> that's the offending bit <tgall_foo> $(PERL) for some dumbass reason is set to no as compared to either turing off this portion of the build or just failing the configure <tgall_foo> grep -r PERL * <tgall_foo> config.log:ac_cv_path_PERL=no <tgall_foo> config.log:PERL='no' <tgall_foo> config.make:PERL = no <tgall_foo> config.status:s,@PERL@,no,;t t <tgall_foo> and there's the how PERL is set in config.make ... so that's Mr Perl ... in the library ... with a leadpipe.... So, what happens is the path to perl gets set to "no" and the compile fails. Adding dev-lang/perl to DEPEND when USE=nls solves the problem. In case you're wondering, these are the USE (filtered) that affect glibc on the media for stage3: poseidon default # cat /release/buildroot/amd64-default/tmp/default/stage3-amd64-2008.0/var/db/pkg/sys-libs/glibc-2.6.1/USE amd64 elibc_glibc kernel_linux multilib nls userland_GNU
This will need to be resolved before the next Gentoo release starts up.
*** This bug has been marked as a duplicate of bug 185476 ***