There is no explicit dependency on libidn, so rebuilds from sstate can fail with: | DEBUG: Executing shell function do_configure | cmake: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory When in previous build cmake-native was build after libidn-native. Please fix in master and krogoth.
Hi Martin I can't reappear it. This is my steps: 1. bitbake libidn-native 2. bitbake cmake-native 3. make another build(share the above build sstate) 4. bitbake cmake-native Can you give me more details about you steps?
Martin, please review the steps provided and give any additional details
It sometimes uses libidn from host, but sometimes libidn from native sysroot: OE qemux86@ ~/build/oe-core $ ldd tmp-glibc/sysroots/x86_64-linux/usr/bin/cmake linux-vdso.so.1 (0x00007ffc485a8000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x00007f3fee06e000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f3fede66000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007f3feda6e000) libm.so.6 => /lib64/libm.so.6 (0x00007f3fed766000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007f3fed54e000) libc.so.6 => /lib64/libc.so.6 (0x00007f3fed1ae000) /lib64/ld-linux-x86-64.so.2 (0x00007f3fee2a6000) OE qemux86@ ~/build/oe-core $ bitbake libidn-native OE qemux86@ ~/build/oe-core $ ldd tmp-glibc/sysroots/x86_64-linux/usr/bin/cmake linux-vdso.so.1 (0x00007ffef4208000) libidn.so.11 => /OE/build/oe-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/../lib/libidn.so.11 (0x00007f0292cd6000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f0292ace000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007f02926d6000) libm.so.6 => /lib64/libm.so.6 (0x00007f02923ce000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007f02921b6000) libc.so.6 => /lib64/libc.so.6 (0x00007f0291e16000) /lib64/ld-linux-x86-64.so.2 (0x00007f0292f0e000) So when cmake is built on host with net-dns/libidn installed (or libidn-native built before cmake-native) and then this cmake build from sstate is reused on host without net-dns/libidn installed it will fail as shown in description.
It should be possible to reproduce also with cmake target build if you disable libidn PACKAGECONFIG in gnutls or gnutls PACKAGECONFIG in curl.
You need to test it on host without libidn installed, see comments above.
This is on host without libidn installed: rm -rf tmp-glibc bitbake -c cleansstate cmake-native && bitbake -c build cmake-native mv tmp-glibc/work/x86_64-linux/cmake-native/*/ cmake-native-no-libidn rm -rf tmp-glibc bitbake -c cleansstate cmake-native && bitbake -c build libidn-native && bitbake -c build cmake-native mv tmp-glibc/work/x86_64-linux/cmake-native/*/ cmake-native-libidn OE qemux86@ ~/build/oe-core $ ldd cmake-native-*/image/OE/build/oe-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/cmake cmake-native-libidn/image/OE/build/oe-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/cmake: linux-vdso.so.1 (0x00007ffdab3c0000) libidn.so.11 => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c636be000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007f9c632c6000) libm.so.6 => /lib64/libm.so.6 (0x00007f9c62fbe000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007f9c62da6000) libc.so.6 => /lib64/libc.so.6 (0x00007f9c62a06000) /lib64/ld-linux-x86-64.so.2 (0x00007f9c638c6000) cmake-native-no-libidn/image/OE/build/oe-core/tmp-glibc/sysroots/x86_64-linux/usr/bin/cmake: linux-vdso.so.1 (0x00007fff53710000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f61f5996000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libstdc++.so.6 (0x00007f61f559e000) libm.so.6 => /lib64/libm.so.6 (0x00007f61f5296000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/libgcc_s.so.1 (0x00007f61f507e000) libc.so.6 => /lib64/libc.so.6 (0x00007f61f4cde000) /lib64/ld-linux-x86-64.so.2 (0x00007f61f5b9e000) On host with libidn installed, you will probably see libidn support always enabled (even without libidn-native in OE sysroot) and when the lib isn't in sysroot, the one from host is used instead - so you won't notice cmake binary failing. But once such cmake-native sstate archive is re-used on host without libidn installed it will start failing.
Things got even worse yesterday thanks to binutils upgrade and also missing openssl-native dependency, see: http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125007.html
I'm getting build problems for cmake on oe-core/384cf92 in a debian jessie system It build fine, but it fails to install with: [ 87%] Built target memcheck_fail [ 90%] Built target CPackLib [ 91%] Built target cpack [100%] Built target CTestLib [100%] Built target ctest Install the project... bin/cmake: /home/igalia/clopez/yocto/commit-builds/upstream/builds/qemux86-64/tmp-glibc/sysroots/x86_64-linux/usr/lib/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by bin/cmake) bin/cmake: /home/igalia/clopez/yocto/commit-builds/upstream/builds/qemux86-64/tmp-glibc/sysroots/x86_64-linux/usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by bin/cmake) bin/cmake: /home/igalia/clopez/yocto/commit-builds/upstream/builds/qemux86-64/tmp-glibc/sysroots/x86_64-linux/usr/lib/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by bin/cmake) Makefile:72: recipe for target 'install' failed make: *** [install] Error 1 ERROR: Function failed: do_install (log file is located at /home/igalia/clopez/yocto/commit-builds/upstream/builds/qemux86-64/tmp-glibc/work/x86_64-linux/cmake-native/3.6.1-r0/temp/log.do_install.33739) I got it working by adding the suggested openssl-native dependency. --- a/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb +++ b/meta/recipes-devtools/cmake/cmake-native_3.6.1.bb @@ -2,7 +2,7 @@ require cmake.inc inherit native # Using cmake's internal libarchive, so some dependencies are needed -DEPENDS += "bzip2-native zlib-native" +DEPENDS += "bzip2-native zlib-native openssl-native" SRC_URI += "\ file://cmlibarchive-disable-ext2fs.patch \
Are openssl/idn worth having as build dependencies for our native needs? Not sure what a build system is using those for at all to be honest!
> Are openssl/idn worth having as build dependencies for our native needs? Not sure what a build system is using those for at all to be honest! I don't know how much these add of build time, but in current state of things when openssl is autodetected from host or from native sysroot and these 2 versions have different ABI (because openssl versioned symbols patch we have in OE's openssl) - it doesn't work at all. You either build against OE's openssl ABI and then when it doesn't get populated in sysroot soon enough, it will use openssl from host and fail. Or it autodetects openssl from host when it's not in native sysroot yet, but then when it gets populated in native sysroot it will again start failing, because it will try to use incompatible ABI again.
Patches on the list. Ended up with depending on curl-native as then cmake-native won't look for openssl or libidn itself.
Fixed in oe-core f9366799aaf4ad2b98345743c7129fa94d092880.