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: wd@...
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead