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 [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
