[Buildroot] Extra package libraries not resolved on target system (Xilinx aarch64)

John Moon johncarlmoon at gmail.com
Mon Jan 23 16:56:45 UTC 2017


Hi,

Thanks for noting that the toolchain versions were kind of old - we
found that Xilinx had released a newer version of the toolchain with
GCC 5.x and headers 4.6.x. Using this toolchain, the Debian style
/lib/<tuple> paths are gone and the programs are resolving their libs
correctly. Thank you!

John

On Fri, Jan 20, 2017 at 12:11 PM, Peter Korsgaard <peter at korsgaard.com> wrote:
>
> >>>>> "John" == John Moon <johncarlmoon at gmail.com> writes:
>
> Hi,
>
>  > Using the Xilinx SDK aarch64 toolchain with Buildroot, extra packages are
>  > having trouble resolving their libraries on the target system. For example,
>  > openssh requires libcrypto.so.1.0.0, but can't find that library when
>  > running ssh-keygen:
>
> Is this toolchain publicly available somewhere?
>
>
>  > # LD_DEBUG=libs ssh-keygen
>
>  >       1653:     find library=libcrypto.so.1.0.0 [0]; searching
>
>  >       1653:      search cache=/etc/ld.so.cache
>
>  >       1653:      search
>  > path=/lib/aarch64-linux-gnu/tls/aarch64:/lib/aarch64-linux-gnu/tls:/lib/aarch64-linux-gnu/aarch64:/lib/aarch64-linux-gnu:/usr/lib/aarch)
>
> So it seems to be using Debian style /lib/<tuple> library paths.
>
>
>  > ssh-keygen: error while loading shared libraries: libcrypto.so.1.0.0:
>  > cannot open shared object file: No such file or directory
>
>
>  > However, the library *does* exist in /usr/lib. If I create a symlink on the
>  > target (ln -s /usr/lib/* /lib/aarch64-linux-gnu/), then everything resolves
>  > correctly.
>
> What Buildroot version are you using? The logic in
> toolchain/external/pkg-toolchain-external.mk should normally create such
> a symlink for you if it is able to detect the ARCH_LIB_DIR with this
> logic:
>
> # Create a symlink from (usr/)$(ARCH_LIB_DIR) to lib.
> # Note: the skeleton package additionally creates lib32->lib or lib64->lib
> # (as appropriate)
> #
> # $1: destination directory (TARGET_DIR / STAGING_DIR)
> create_lib_symlinks = \
>        $(Q)DESTDIR="$(strip $1)" ; \
>        ARCH_LIB_DIR="$(call toolchain_find_libdir,$(TOOLCHAIN_EXTERNAL_CC) $(TOOLCHAIN_EXTERNAL_CFLAGS))" ; \
>        if [ ! -e "$${DESTDIR}/$${ARCH_LIB_DIR}" -a ! -e "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ]; then \
>                ln -snf lib "$${DESTDIR}/$${ARCH_LIB_DIR}" ; \
>                ln -snf lib "$${DESTDIR}/usr/$${ARCH_LIB_DIR}" ; \
>        fi
>
> Perhaps you can add some echo statements here to see what goes wrong?
>
>  > Why are the binaries looking for their libraries in /lib/<tuple>
>  > and /usr/lib/<tuple> instead of just /lib and /usr/lib?
>
> Because the toolchain is configured to do so.
>
>
>  > The toolchain has GCC version 4.9.x, kernel headers 4.4.x, and I'm using
>  > glibc/eglibc.
>
> That's quite old for aarch64. Is there any specific reason why you are
> using this toolchain?
>
>  > Thank you - this is my first post to the mailing list - hopefully I'm not
>  > making any faux pas's.
>
> No no, don't worry ;)
>
> --
> Bye, Peter Korsgaard



More information about the buildroot mailing list