Re: [Ltib] ltib host libs vs x86 platform

[Stuart Hughes]

Hi Mike,

Unfortunately in this case /opt/ltib is deliberately making use of the
system area (/lib, /usr/lib etc).  The idea of this area is to add some
packages to the host that LTIB needs without building a whole host
distribution (or polluting it).  So I don't think you can make use of
this area for what you want (without breaking its intended use).

Your best bet is to make an x86 BSP and build your packages in that
container.  However, you will need to chroot into this area to run your
unit tests.  The reason is glibc is built to find its libraries in /lib,
/usr/lib after deployment to a platform.  So unless you chroot, you're
going to pick up your host's libraries.

Regards, Stuart

On 05/05/13 04:57, Mike Goins wrote:
> 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.
> 
> _______________________________________________
> LTIB home page: http://ltib.org
> 
> Ltib mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/ltib
>