The fail message we obtain in buildroot-compiled chroot environment: bash-4.3# ssh bash: /usr/bin/ssh: No such file or directory It happens because ssh execute file does not contain proper dynamic linker way: # readelf /tmp/usr/bin/ssh -l ... [Requesting program interpreter: /home/cf/e2k/mcst.rel-21-0.fs/2016-04-12/e2k-generic-linux.cross/lib64/ld-linux.so.2] ... The proper way to dynamic linker we set with BR2_TARGET_LDFLAGS="-Wl,-dynamic-linker,/lib/ld-linux.so.2" option in .config file. This scheme works fine in different packages (busybox, bash ...). In case of openssh package the option does not pass through package/openssh/openssh.mk file: ... OPENSSH_CONF_ENV = LD="$(TARGET_CC)" LDFLAGS="$(TARGET_CFLAGS)" ... Here internal openssh option LDFLAGS contain only common $(TARGET_CFLAGS). Common $(TARGET_LDFLAGS) does not pass inside openssh build system here. If we change this line to the next: ... OPENSSH_CONF_ENV = LD="$(TARGET_CC)" LDFLAGS="$(TARGET_CFLAGS) $(TARGET_LDFLAGS)" ... ssh works fine.
It works just fine here, and there is absolutely no need to pass custom LDFLAGS for this to work. The default dynamic linker path is set by the cross-compiler and is correct. I've just tested the following Buildroot defconfig: BR2_x86_64=y BR2_x86_core2=y BR2_TOOLCHAIN_EXTERNAL=y BR2_PACKAGE_OPENSSH=y ssh has the correct dynamic linker path: readelf -a output/target/usr/bin/ssh | grep -i interpreter [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] and when I extract the rootfs.tar and chroot into it: $ sudo chroot rootfs /bin/sh / # ssh -l Couldn't open /dev/null: No such file or directory / # mount -t devtmpfs none /dev / # ssh -l option requires an argument -- l usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command] So I think you have something in your environment that causes the cross-compiler to encode a wrong path to the dynamic linker.
I thought that BR2_TARGET_LDFLAGS option should be pass to the linker when building any package. As it is mentioned in menuconfig's help: "BR2_TARGET_LDFLAGS: Extra options to pass to the linker when building for the target.". In case of openssh package the option is not passed to the linker.