Hello, I have a build problem which is caused by libraries not being found.
It's a recipe to build the U-Boot bot loader which includes running the "mkimage" tool generated during this build. This fails as follows: ... | LD u-boot | OBJCOPY u-boot.bin | MKIMAGE u-boot.img | /opt/eldk/build/eldk-rel-v5.6-2014-08-17-fe344de-mcvevk/tmp/work/mcvevk-linux-gnueabi/u-boot/v2014.10+gitAUTOINC+c43fd23cf6-r0/git/tools/mkimage: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory | make: *** [u-boot.img] Error 127 I verified that the LD_LIBRARY_PATH variable is not set when these commands are run, which explains the problem: -> ldd /opt/eldk/build/eldk-rel-v5.6-2014-08-17-fe344de-mcvevk/tmp/work/mcvevk-linux-gnueabi/u-boot/v2014.10+gitAUTOINC+c43fd23cf6-r0/git/tools/mkimage linux-vdso.so.1 => (0x00007fff6a7fe000) libssl.so.1.0.0 => not found libcrypto.so.1.0.0 => not found libc.so.6 => /lib64/libc.so.6 (0x0000003396000000) /lib64/ld-linux-x86-64.so.2 (0x0000003395c00000) The reason is that this system uses a different version of these libraries: -> ls -l /lib64/libssl.so.1* /lib64/libcrypto.so.1* -rwxr-xr-x 1 root root 1972736 Aug 8 13:48 /lib64/libcrypto.so.1.0.1e lrwxrwxrwx 1 root root 19 Sep 2 23:49 /lib64/libcrypto.so.10 -> libcrypto.so.1.0.1e -rwxr-xr-x 1 root root 446040 Aug 8 13:48 /lib64/libssl.so.1.0.1e lrwxrwxrwx 1 root root 16 Sep 2 23:49 /lib64/libssl.so.10 -> libssl.so.1.0.1e So the host system is using one version of these libraries, while the build is done against a different version. I can work around this problem by adding the build's sysroot libraries to LD_LIBRARY_PATH, like that: do_compile_prepend () { export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:${STAGING_LIBDIR_NATIVE}:${STAGING_LIBDIR_NATIVE}/../../lib } But this looks wrong to me - if this was needed, should it not be done on a much higer level, at some central point so that all tools run during the build will automatically pick up the matching libraries from sysroot? Or is this some problem anywhere else in my own code? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If I had to live my life again, I'd make the same mistakes, only sooner. -- Tallulah Bankhead -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto