error while loading shared libraries: cannot open shared object file: No such file or directory

[John Reiser]

The runtime linker+loader /lib/ld-linux-armhf.so.3 makes an incorrect check for a loadable shared library. Subroutine check_arm_attributes_hfabi() in file glibc/elf/dl-load.c currently looks only at the Elf(W)Shdr records of type SHT_ARM_ATTRIBUTES, and ignores Elf(W)Ehdr.e_flags. The result is that some shared libraries that do work correctly (in every respect) are refused loading with the message
   <main_program_path>: error while loading shared libraries: <shared_library_name>: cannot open shared object file: No such file or directory
In particular, when a shared library has no Shdr records (.e_shnum == 0) then ld-linux-armhf refuses to load that library, even though e_flags indicates that everything is correct.

An ELF file has two sets of information for a module (main program or shared library): the execution view, and the linking view. The execution view is in Ehdr and Phdr, the linking view is in Ehdr and Shdr. The design intent is that the static linker /bin/ld takes input only from the linking view, and the runtime linker+loader ld-linux-armhf takes input only from the execution view. Any use of Shdr records by ld-linux-armhf is a violation of the design intent.

In this particular case, the relevant information in SHT_ARM_ATTRIBUTES regarding the use of the floating-point ABI is summarized in flag bits in .e_flags, namely the EF_ARM_ABI_FLOAT_HARD bit. So if there are no Shdr records, then the e_flags should be consulted. (Actually all the code that delves into Shdr could [should] be replaced by a simple check of e_flags; but keeping the existing Shdr code then checking e_flags last is in some sense the "smallest" fix.)

A patch which adds the check on e_flags is:
--- elf/dl-load.c.orig 2017-08-24 09:51:11.000000000 -0700
+++ elf/dl-load.c 2017-08-24 14:47:48.525189652 -0700
@@ -1628,6 +1628,8 @@
         }
     }

+ /* This one statement using e_flags could [should] replace EVERYTHING above! */
+ *is_hf = !!(ehdr->e_flags & EF_ARM_ABI_FLOAT_HARD);
   return 0;
 }

[The problem in this bug report was discovered in https://github.com/upx/upx/issues/116 .]

$ lsb_release -rd
Description: Ubuntu 16.04.2 LTS
Release: 16.04
$ apt-cache policy libc6:armhf
libc6:
  Installed: 2.23-0ubuntu5
  Candidate: 2.23-0ubuntu9
  Version table:
     2.23-0ubuntu9 500
        500 http://ports.ubuntu.com xenial-updates/main armhf Packages
        500 http://ports.ubuntu.com xenial-security/main armhf Packages
 *** 2.23-0ubuntu5 100
        100 /var/lib/dpkg/status
     2.23-0ubuntu3 500
        500 http://ports.ubuntu.com xenial/main armhf Packages

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: libc6:armhf 2.23-0ubuntu5
Uname: Linux 4.4.38-v7+ armv7l
ApportVersion: 2.20.1-0ubuntu2.5
Architecture: armhf
CurrentDesktop: XFCE
Date: Thu Aug 24 15:10:30 2017
Dependencies:
 gcc-6-base 6.0.1-0ubuntu1
 libc6 2.23-0ubuntu5
 libgcc1 1:6.0.1-0ubuntu1
SourcePackage: glibc
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Tobias Hieta (to5ias)]

Sorry to drag up a very old bug like this - but this still seems to be an issue in new ubuntu/debian based distributions. I ran into this issue when using llvm-strip and it doesn't preserve .ARM.attributes - I have written a patch against llvm-strip that's being discussed here: https://reviews.llvm.org/D69188

But this is something that seems to be introduced in the patchset used and not upstream glibc