[Ltib] ltib host libs vs x86 platform

[Mike Goins]

I'm implementing some unit testing which requires the same version of
some of the ltib packages (that is, can't depend on the host to have
the same version, even if it is installed).   I thought I could easily
get by with adding the some of the same packages to
host/ltib.preconfig as the platform and set the unit testing
lib/header discovery to /opt/ltib.

The issue with this implementation is that when building host
packages, it does not first find libs/headers in /opt/ltib.  Example
is libxml2, which depends on libz.   libz has been selected for the
host but when building libxml2, the host libz is used instead of
/opt/ltib/usr/lib:

$ ldd /opt/ltib/usr/lib/libxml2.so.2.6.28
linux-vdso.so.1 =>  (0x00007fff56dd2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f075ef9f000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f075ed88000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f075ea8b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f075e6cc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f075f51a000)


I know the host packages were not really designed for this, but I
would love for it to serve double duty.  Can someone point me in the
approximate area in the host build where I could use a sysroot type
option for host builds?

The other, likely cleaner, option is to just have plain old x86
platform.  I managed to cobble one together, no libc or kernel, but
still seem to be having a problem with picking up host libs:

$ ls rootfs_test/usr/lib/libz*
rootfs_test/usr/lib/libz.a  rootfs_test/usr/lib/libz.so
rootfs_test/usr/lib/libz.so.1.2.3
rootfs_test/usr/lib/libz.so.1

$ ldd litb/rootfs_test/usr/lib/libxml2.so.2.6.28
linux-vdso.so.1 =>  (0x00007fff487ff000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4d6d6e7000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4d6d4d0000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4d6d1d3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4d6ce14000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4d6dc62000)

Same issue, I suspect.   I thought for sure that platform builds would
avoid the native host.