[ hope this is not far off topic ] While attempting to bootstrap GCC 4.8.0 on a PowerPC ( PowerMac G5 ) based Debian 7 system I ultimately run into a problem where the stage 2 process seems to need libz in some other format than what I have in /usr/local/lib : vanth $ ll /usr/local/lib/libz* -rw-r--r-- 1 dclarke adbs 107426 Mar 23 06:31 /usr/local/lib/libz.a lrwxrwxrwx 1 dclarke adbs 13 Mar 23 06:31 /usr/local/lib/libz.so -> libz.so.1.2.7 lrwxrwxrwx 1 dclarke adbs 13 Mar 23 06:31 /usr/local/lib/libz.so.1 -> libz.so.1.2.7 -rwxr-xr-x 1 dclarke adbs 97738 Mar 23 06:31 /usr/local/lib/libz.so.1.2.7 vanth $ readelf -h /usr/local/lib/libz.so.1.2.7 ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: PowerPC Version: 0x1 Entry point address: 0x1cc0 Start of program headers: 52 (bytes into file) Start of section headers: 87548 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 6 Size of section headers: 40 (bytes) Number of section headers: 32 Section header string table index: 29 So I am thinking that the bootstrap process is looking for a 64-bit libz.so and while I would love to comply with this need I just don't know *where* the runtime linker looks for such a thing. In the Sparc Solaris world one may simply drop a 64-bit lib under /usr/local/lib/sparcv9 and the linker will automagically look there as a matter of course if the architecture demands it. Certainly when the RPATH in the ELF dynamic section specifies this location! I don't know if the same can be said for a PPC970 processor and some sort of magic /usr/local/lib64 ? Perhaps I need to insert -Wl,--rpath=/usr/local/lib64:/usr/local/lib and then the runtime linker will pick the right lib? So the question is, how does one solve this problem on Linux ? Without doing obscene things to the system config I mean and with, I hope, an elegant solution that seems to parallel the existence of both a 32-bit libc and a 64-bit libc : vanth $ ls -lap /lib64/libc-2.13.so -rwxr-xr-x 1 root root 1753816 Dec 30 18:49 /lib64/libc-2.13.so vanth $ ls -lap /lib/powerpc-linux-gnu/libc-2.13.so -rwxr-xr-x 1 root root 1528016 Dec 30 18:47 /lib/powerpc-linux-gnu/libc-2.13.so Why would the /lib64 edition even be looked at in such a bizarre location on the root filesystem as opposed to something more sensible such as /lib/powerpc64-linux-gnu ? I guess what I am really saying, is there some elegant way in which Linux organizes its lib locations for those architectures that support both 64-bit and 32-bit binaries? Dennis
