/usr/bin/ld: cannot find -lz

/usr/bin/ld: cannot find -lz

[Dennis Clarke]

[ 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