Missing link /lib/ld-linux.so.3

[mwittig]

This will be required , for example, for executables which have been built on Raspian which require /lib/ld-linux.so.3. For example

$ file vhduino
vhduino: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 3.1.9, not stripped
$ sudo ./vhduino
sudo: unable to execute ./vhduino: No such file or directory

The issue can be resolved by creating a linka s follows:

$ sudo ln -s /lib/arm-linux-gnueabihf/ld-linux.so.3 /lib/ld-linux.so.3
$ sudo ./vhduino
ready

I think this should be handled as some users also want to install/run other stuff on osmc.

How to reproduce - You can pull vhduino from https://github.com/pimatic/homeduinojs
Suggested fixture - Add the symbolic link as outlined above

[samnazarko]

Hello

We provide binary compatibility guarantee for binaries compiled using Raspbian. However we recommend binaries are compiled for their native target for performance and compatibility reasons.

OSMC for Pi1/0 uses Raspbian as upstream for debootstrap process
OSMC for Pi2/3 uses Debian as upstream for debootstrap process

I had a look at the vhduino binary.

osmc@osmc:~$ objdump -s --section .comment vhduino

vhduino:     file format elf32-littlearm

Contents of section .comment:
 0000 4743433a 20286372 6f737374 6f6f6c2d  GCC: (crosstool-
 0010 4e472031 2e31352e 32292034 2e372e31  NG 1.15.2) 4.7.1
 0020 20323031 32303430 32202870 72657265   20120402 (prere
 0030 6c656173 652900                      lease).  

This shows the vhduino binary has been cross compiled with a very old toolchain. This toolchain is deprecated. It also does not follow the GNU triplet standards, which is why there are problems with the LD path. This could suggest the toolchain is old, or Crosstool was not configured correctly. I'd also check other utilities like libtool as well.

I recommend the author recompiles the binary with a more modern toolchain if they wish to distribute it. If they compile it on Raspbian, it will work without issue on OSMC.

[samnazarko]

If the binary is compiled using a recent version of Raspbian, Raspbian Lite or Minibian it will work. It will also work if you use the official Raspberry Pi cross-compilation tools.

On OSMC for ARMv7 (Pi2/Pi3), which I assume is affected, I see:

osmc@osmc:~$ cat /etc/ld.so.conf.d/arm-linux-gnueabihf.conf 
# Multiarch support
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf

Nothing deviates from the standard Debian Jessie implementation here on OSMC, with the exception of an addition to /etc/ld.so.conf.d to add /opt/vc/lib to the default path.

This looks very much an issue with the toolchain. It would be useful to know which device you tested on, and if the Pi 1 version of OSMC is affected.

Is there a reason the binary cannot be recompiled using a compatible toolchain? We haven't had any reports of this issue before.

[mwittig]

Possibly related to https://wiki.debian.org/Multiarch/LibraryPathOverview#ELF_interpreter-1

"Executables built with the old ELF interpreter will not run on a system that only provides the multiarch install location. This is clearly not OK. To provide backwards compatibility, even a multiarch-capable system will need to install ELF interpreters at the old locations as well, possibly via symlinks. (Note that any given system can only be compatible in this way with one architecture, except for lucky circumstances.) "

I think this is exactly what is done by recent Raspbian Releases and other Debian flavors ...

cat /etc/issue
Raspbian GNU/Linux 8 \n \l

$ ls -l /lib/ld-linux.so.3
lrwxrwxrwx 1 root root 24 Feb 26  2016 /lib/ld-linux.so.3 -> /lib/ld-linux-armhf.so.3

[samnazarko]

@hvdwolf I can't see your comment any more. Did you delete it?

[samnazarko]

Thanks for the background.

Using the symlink approach will break multi-arch support, which may not be ideal. Needs some thought.

[hvdwolf]

@samnazarko Yes, it was exactly what you mentioned about /etc/ld.so.conf.d/arm-linux-gnueabihf.conf, so I wanted to remove the maybe confusing post. Maybe I should not have done that.

[mwittig]

I was also suprised the comment has disappeared somehow. Anyhow, I have checked the content of /etc/ld.so.conf.d/arm-linux-gnueabihf.conf is the same as on Raspbian. I think the lines from the Debian Wiki point into the right direction as they explicitly require legacy support.

EDIT: ok, if it breaks multi-arch support this might be an issue with other software used on the system

[samnazarko]

I suspect we can do this on ARM.

x64 version of OSMC this is not feasible.

[mwittig]

Ah, yes. On Intel you may require support for 32-bit also. On ARM it is only 32-bit (for Raspbian, at least)

[samnazarko]

I think 29154da is what we need.

• Only works for new installs
• Easier to check for regressions
• Don't need to check target is applicable in postinst in package

[mwittig]

Excellent, thank you very much for looking into this so quickly

[samnazarko]

Fixed in master. Will be ready for Sunday. Thanks again.

[juansuerogit]

i download dotnet-linux-arm.latest.tar.gz on 12/10 and im getting a
robot@ev3dev:~/dotnetlinux$ ./dotnet
-bash: ./dotnet: No such file or directory

i installed it in a local directory as well as
robot@ev3dev:~$ /usr/bin/dotnet/dotnet
-bash: /usr/bin/dotnet/dotnet: No such file or directory

is there some preinstallation i need to install?
i did a sudo apt-get upgrade before trying.

here are some diagnostics from my linux system
cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=ev3dev
ID_LIKE=debian
HOME_URL="http://www.ev3dev.org/"
SUPPORT_URL="http://www.ev3dev.org/support"
BUG_REPORT_URL="https://github.com/ev3dev/ev3dev/issues"
robot@ev3dev:$ cat /etc/debian_version
8.5
robot@ev3dev:$

robot@ev3dev:~$ lscpu
Architecture: armv5tejl
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Model name: ARM926EJ-S rev 5 (v5l)

====update...

i tried hacking around by opening the dotnet executable and saw a path in there. so i copied one of the sym links in the lib directory so it could match that path and something changed.

now i get a segmentation fault.

the path was in the first few lines of the dotnet exe its: /lib/ld-linux-armhf.so.3
when i put everything back the way it was i get the original

-bash: ./dotnet: No such file or directory silent crash.

any ideas?

[samnazarko]

The original problem was resolved. You don't mention which device you're running OSMC. If you're using a Pi, this may be the issue: https://github.com/dotnet/core-setup/issues/2559.

[juansuerogit]

thanks. not using pi.. using ev3.. someone helped me on another thread and said the following.
dotnet "arm" is armv7, so it won't run on EV3, which is armv5 (for the same reason nodejs doesn't work anymore). See dotnet/corert#477

[samnazarko]

Is this on an OSMC system?

[juansuerogit]

its the lego mindstorms ev3 robot ( debian-jesse ). chip is "ARM9" but apparently from the output above runs the ARM5 instruction set? long story short it cant run dotnet core. and runs a very low level version of nodejs for the same reasons.

[samnazarko]

It's correct that dot net core uses ARMv7 instructions. This is why it won't work on BCM2835 products.
Unfortunately we can only provide support for OSMC and supported OSMC devices , not Debian itself.

Only MS can change this unfortunately.
Unfortunately ARM naming is a bit confusing. ARM11 for example is armv6 architecture.

[juansuerogit]

my only angle now is to spend 150 bucks on a brickpi + raspberry pi combo.

[samnazarko]

Sorry -- not sure how this is related to OSMC.