perl unconditionally adds /lib64 /lib32 etc. dirs to the search path. Perl is, however, stupid enough to just list .so files in them to determine if it can build gdbm and db support. Obviously, the toolchain won't find the libs if they are for another architecture (multilib), hence the ebuild should try to only add what's usable. This is tricky, since at bootstrap scanelf isn't there yet, so probably we should try to compile/link against some object we find in a lib-dir and if that succeeds add the dir to the libdirs-list.
I think I fixed this now too by compiling a small program, linking against a library to verify that the libs from the given dir are compatible
The check to see if the libdirs are not non-native doesn't function correctly. I was following the solaris build instructions (http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml) and was bootstrapping findutils: emerge --oneshot findutils Perl failed to emerge (build log attached). my prefix is i686 my host is: /etc/issue: Red Hat Enterprise Linux Client release 5.6 (Tikanga) uname -a: Linux <omitted> 2.6.18-238.5.1.el5 #1 SMP Mon Feb 21 05:52:39 EST 2011 x86_64 GNU/Linux as evidenced in the logs, libm wasn't linked properly. echo {,/usr}/lib*/libm.so* outputs: /lib64/libm.so.6 /lib/libm.so.6 /usr/lib64/libm.so /usr/lib/libm.so file -L /usr/lib/libm.so outputs: /usr/lib/libm.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped With the first modified ebuild, I print the library path (myconf), and it does not contain /usr/lib (line 52) output for this ebuild is attached. With the second modified ebuild, perl builds properly.
Created attachment 276299 [details] ebuild to print libpath
Created attachment 276301 [details] The build log for the modified ebuild showing libpath.
Created attachment 276303 [details] Sucessful ebuild
reopening for the last comments
*** Bug 367163 has been marked as a duplicate of this bug. ***
I just checked in a change to the way the libpaths are determined. I hope this works more reliably now.
*** Bug 389225 has been marked as a duplicate of this bug. ***
No problems encountered any more
