Get the complete list of .so dependencies for Qt application? [duplicate]
My Qt application should run on Linux distributions that don’t have Qt installed and even have older version of glibc and so on. So I decided to distribute those libraries with my apllication. How could I get the complete list of dependencies for my application, including the dependencies of Qt and system libraries like glibc and others? And is there any other way I could get my application running on Linux distributions that don’t have glibc and other packages of expected versions?
It is usually a bad idea to use a different libc than the one that is installed on the system, because it’s tricky to do it right. Also, the Linux way is to depend on the system’s package manager to drag dependencies in, not to bundle them with your program. What are you gonna do when you realize your bundled libx11 isn’t compatible with the machine’s X server?
@LaszloPapp not the way it was intended. We end up with building separate package almost for every distribution…
2 Answers 2
It is possible, but it is a bit tricky, especially if you need glibc as well. In that case, you even need to make sure that not only libc is appropriate, but you bring your corresponding ld ‘so’ with it as well. Otherwise, you might get a segfault after the libc entry point, but before your main function.
Essentially, when you will try to run your application, you will see the missing libraries until you add all.
Try: ldd -r foo -> That will tell you what libraries are necessary for an executable or library. Here you can find the man page of it.
Here is an example from my system: ldd -r /usr/lib/libQt5Quick.so.5.1.0
linux-vdso.so.1 (0x00007fffbb3fe000) libQt5Qml.so.5 => /usr/lib/libQt5Qml.so.5 (0x00007f376576b000) libQt5Network.so.5 => /usr/lib/libQt5Network.so.5 (0x00007f3765433000) libQt5Gui.so.5 => /usr/lib/libQt5Gui.so.5 (0x00007f3764e13000) libQt5Core.so.5 => /usr/lib/libQt5Core.so.5 (0x00007f3764800000) libQt5V8.so.5 => /usr/lib/libQt5V8.so.5 (0x00007f376415a000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f3763e2c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3763b27000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f3763824000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f376347a000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f376325b000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f3763045000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f3762dd9000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f37629ce000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007f3762799000) libicui18n.so.51 => /usr/lib/libicui18n.so.51 (0x00007f3762398000) libicuuc.so.51 => /usr/lib/libicuuc.so.51 (0x00007f3762021000) libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x00007f3761dc4000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f3761bc0000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007f37618c1000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f37616b9000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f37614a3000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007f3766166000) libnvidia-tls.so.325.15 => /usr/lib/libnvidia-tls.so.325.15 (0x00007f376129f000) libnvidia-glcore.so.325.15 => /usr/lib/libnvidia-glcore.so.325.15 (0x00007f375ebbf000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f375e884000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f375e671000) libicudata.so.51 => /usr/lib/libicudata.so.51 (0x00007f375cf27000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f375ccbc000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f375ca9d000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f375c898000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f375c692000) How to list dependencies of c/c++ static library?
For a static library (.a file), how to list the module-level dependencies of it? I know for a shared library (.so), we can use objdump or readelf to do this:
00000000 DF UND 00000000 QByteArray::mid(int, int) const 00000000 DF UND 00000000 QUrl::fromEncoded(QByteArray const&) 00000000 DF UND 00000000 QFileInfo::fileName() const
2 Answers 2
A static library have no such list of dependencies.
A static library is nothing more than an archive of object files. And as object files doesn’t know what libraries they depend on, neither can a static library.
I’d say the reason for this is that static library is not linked. Therefore, no one in the build chain so far was responsible for adding such information to it.
@Jan Smrčina @Some programmer dude But how can a static library be generated without knowing that information? For example, library A uses a function defined in another library B. If we don’t add something like #include «B.h» , can A be generated? In that case, can we say A depends on B?
@bagebb Just like any other object file. The ar command used to create static libraries is a plain and very simple ARchiver. For static libraries it’s up to you to keep track of the dependencies, and link with them explicitly. It’s nothing that the linker is capable of, all it does is basically to extract the object files and link with them.
@Some programmer dude So does it mean for the case I mentioned above, if I don’t specify #include «B.h» , static library A can still be created, but if I want to use A to generated an executable, I have to link to B somewhere?
@Some programmer dude is right, but what you can do is build a simple program using this library statically and then check with ldd -v what are the dependencies.
This is helpful. The hard part though is building it because you would have to know all the dependencies to specify them at build time, so you already have this information, or you would be in the same predicament. ‘ldd -v’ would be useful to inspect applications that someone else built, but I’d say that if you have something built statically in-hand, your fastest path is the ask the person who built it what the dependencies are.
Determine direct shared object dependencies of a Linux binary?
How can I easily find out the direct shared object dependencies of a Linux binary in ELF format? I’m aware of the ldd tool, but that appears to output all dependencies of a binary, including the dependencies of any shared objects that binary is dependent on.
4 Answers 4
You can use readelf to explore the ELF headers. readelf -d will list the direct dependencies as NEEDED sections.
$ readelf -d elfbin Dynamic section at offset 0xe30 contains 22 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libssl.so.1.0.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000c (INIT) 0x400520 0x000000000000000d (FINI) 0x400758 . This is great. Unlike ldd, readelf can inspect a cross-platform binary (i.e. inspect an ARM executable from x86-64 linux.)
If you want to find dependencies recursively (including dependencies of dependencies, dependencies of dependencies of dependencies and so on)…
ldd would not work with an executable — only for finding out the dependencies of shared libraries it is useful.
The objdump tool can tell you this information. If you invoke objdump with the -x option, to get it to output all headers then you’ll find the shared object dependencies right at the start in the «Dynamic Section».
For example running objdump -x /usr/lib/libXpm.so.4 on my system gives the following information in the «Dynamic Section»:
Dynamic Section: NEEDED libX11.so.6 NEEDED libc.so.6 SONAME libXpm.so.4 INIT 0x0000000000002450 FINI 0x000000000000e0e8 GNU_HASH 0x00000000000001f0 STRTAB 0x00000000000011a8 SYMTAB 0x0000000000000470 STRSZ 0x0000000000000813 SYMENT 0x0000000000000018 PLTGOT 0x000000000020ffe8 PLTRELSZ 0x00000000000005e8 PLTREL 0x0000000000000007 JMPREL 0x0000000000001e68 RELA 0x0000000000001b38 RELASZ 0x0000000000000330 RELAENT 0x0000000000000018 VERNEED 0x0000000000001ad8 VERNEEDNUM 0x0000000000000001 VERSYM 0x00000000000019bc RELACOUNT 0x000000000000001b The direct shared object dependencies are listing as ‘NEEDED’ values. So in the example above, libXpm.so.4 on my system just needs libX11.so.6 and libc.so.6 .
It’s important to note that this doesn’t mean that all the symbols needed by the binary being passed to objdump will be present in the libraries, but it does at least show what libraries the loader will try to load when loading the binary.