ld skips shared library

Question

I am trying to deploy a Qt application by providing the Qt libraries as shared libraries in a directory and pointing ld to them using LD_LIBRARY_PATH. This works for all Qt libraries such as libQt5Network or libQt5Gui, but not for libQt5Core which is somehow not found and the system version is used instead.

Using LD_DEBUG=all I can see that ld tries the file which exists, but skips it

  3705: file=libQt5Core.so.5 [0];  needed by ./app.bin [0]
  3705: find library=libQt5Core.so.5 [0]; searching
  3705:  search path=/home/user/app/lib:/usr/lib64/tls/x86_64/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls/x86_64:/usr/lib64/tls:/usr/lib64/x86_64/x86_64:/usr/lib64/x86_64:/usr/lib64/x86_64:/usr/lib64     (LD_LIBRARY_PATH)
  3705:   trying file=/home/user/app/lib/libQt5Core.so.5 <- this file exists
  3705:   trying file=/usr/lib64/tls/x86_64/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/tls/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/tls/libQt5Core.so.5
  3705:   trying file=/usr/lib64/x86_64/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/x86_64/libQt5Core.so.5
  3705:   trying file=/usr/lib64/libQt5Core.so.5

Both libQt5Core.so.5 and app.bin are 64 bit elf.

Is there any way to find out why ld rejects the file?

score 1 · Accepted Answer · answered May 18 '18 at 16:59

1

Solution is here: https://github.com/Microsoft/WSL/issues/3023

The library contains an ABI note which can be removed using strip to make ld accept the library.

answered May 18 '18 at 16:59

DJohnson

23
4

Running stuff on WSL is kinda a big deal. It should be in the question. – Kuba hasn't forgotten Monica May 18 '18 at 18:18
@KubaOber It was not running on WSL, but it turned out the be the same issue. I was trying to load a library with an ABI tag of 3.17 on a 3.10 kernel. This is why ld rejected the library. – DJohnson May 22 '18 at 06:58
Is it qt bug for that version ? or yocto bug ? who is responsible for this ? – ransh Sep 04 '19 at 06:00

score 1 · Answer 2 · answered Dec 14 '18 at 16:48

The other answer is correct. Just in case the link there gets broken, here's what happened in my case and how I fixed it.

I was running an older kernel, version 3.10, on a system where Qt5 was installed. One of the libraries – namely, libQt5Core.so.5.11.0, has an ELF section .note.ABI-tag, which specifies that the library was compiled for kernel 3.17.0. Presence of this section can be seen via e.g.

objdump -sj .note.ABI-tag /path/to/library.so

And the fact that it's compiled for a newer kernel is revealed by file, with the hard to notice note, "for GNU/Linux 3.17.0", near the end of its output. In my case it was:

/opt/qt511/lib/libQt5Core.so.5.11.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.17.0, BuildID[sha1]=df5f7e933899d1ff629145ab7ca35b2f9bc41843, stripped

So the fix in my case was to run

strip --remove-section=.note.ABI-tag /path/to/library.so

which removed this section and allowed the library to load.

Beware though, that if you do this, you explicitly break the assumptions the library build system may have used, so things may break. In my case they didn't, though.

Thanks, after several days of struggle, it's solved. But Is it qt bug for that version ? or yocto bug ? who is responsible for this ? — ransh, Sep 04 '19 at 06:01
@ransh I have no idea what yocto is, but if your system has a package built for a kernel newer than that installed in the system, I'd call is packaging bug. Ideally, you should file an issue to whomever provided you with this Qt binary package and told that it'll work in your system. — Ruslan, Sep 04 '19 at 07:27

ld skips shared library

2 Answers2