Bug 358875 – bootstrap: perl ebuild should not check non-native libdirs

• Product: Gentoo/Alt
• Status: RESOLVED FIXED

[Description Fabian Groffen 2011-03-14 14:06:23 UTC]

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.

[Comment 1 Fabian Groffen 2011-03-15 20:08:12 UTC]

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

[Comment 2 Alexander Lam 2011-06-08 17:37:20 UTC]

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.

[Comment 3 Alexander Lam 2011-06-08 17:37:43 UTC]

Created attachment 276299 [details]
ebuild to print libpath

[Comment 4 Alexander Lam 2011-06-08 17:38:15 UTC]

Created attachment 276301 [details]
The build log for the modified ebuild showing libpath.

[Comment 5 Alexander Lam 2011-06-08 17:38:38 UTC]

Created attachment 276303 [details]
Sucessful ebuild

[Comment 6 Fabian Groffen 2011-07-09 08:27:10 UTC]

reopening for the last comments

[Comment 7 Fabian Groffen 2011-07-09 08:32:53 UTC]

*** Bug 367163 has been marked as a duplicate of this bug. ***

[Comment 8 Fabian Groffen 2011-07-09 08:48:08 UTC]

I just checked in a change to the way the libpaths are determined.  I hope this works more reliably now.

[Comment 9 Jeremy Olexa (darkside) (RETIRED) 2011-11-02 01:14:49 UTC]

*** Bug 389225 has been marked as a duplicate of this bug. ***

[Comment 10 Fabian Groffen 2011-12-22 10:51:52 UTC]

No problems encountered any more