How to trace the need of a library when linking?

Question

Quick version: why gcc is asking for a specific library? How to trace its dependency while executing gcc?

Long version: I am trying to compile c++ code that uses opencv, which uses ffmpeg. Errors appear When compiling:

//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_alloc@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_free@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_is_initialized@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_close@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_init@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_convert@LIBSWRESAMPLE_2' sin definir

I understand libavcodec.so needs libswresample.so, but I expect to link against libavcodec.so.58, not 57. I want to trace that dependency: I want to know why is gcc asking for that file.

I know it would be better to have only libavcodec.so in the system, but right now I can't get rid of libavcodec.so.57. In my system:

$ ldconfig -p | grep libavcodec
libavcodec.so.58 (libc6,x86-64) => /usr/local/lib/libavcodec.so.58
libavcodec.so.57 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libavcodec.so.57
libavcodec.so (libc6,x86-64) => /usr/local/lib/libavcodec.so  <== This is a link to 58)

If you want to know, gcc command line is this, note there's no -lavcodec there:

g++ -Wl,--trace-symbol=libavcodec -L/usr/local/lib -L"/home/alejandro/Desarrollo eclipse/os1/Thirdparty" -o "os1"  ./src/Converter.o ./src/Frame.o ./src/FrameDrawer.o ./src/Initializer.o ./src/KeyFrame.o ./src/KeyFrameDatabase.o ./src/KeyFrameTriangulacion.o ./src/LocalMapping.o ./src/LoopClosing.o ./src/Map.o ./src/MapDrawer.o ./src/MapPoint.o ./src/ORBextractor.o ./src/ORBmatcher.o ./src/Optimizer.o ./src/PnPsolver.o ./src/PuntoLejano.o ./src/PuntosLejanosDB.o ./src/Sim3Solver.o ./src/System.o ./src/Tracking.o ./src/Video.o ./src/Viewer.o ./src/main.o ./src/osmap.o ./src/osmap.pb.o   -lopencv_core -lopencv_features2d -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_imgproc -lopencv_calib3d -lpthread -lpangolin -lGL -lGLU -lDBoW2 -lg2o -lprotobuf

This command ask for libopencv_videoio.so, which in turn should look for for libavcodec.so.58. Scanning all opencv shared objects:

& ldd -r /usr/local/lib/libopencv_*.so | grep libavcodec
libavcodec.so.58 => /usr/local/lib/libavcodec.so.58 (0x00007f0f03c11000)
libavcodec.so.58 => /usr/local/lib/libavcodec.so.58 (0x00007fb00e3fa000)
libavcodec.so.58 => /usr/local/lib/libavcodec.so.58 (0x00007f916be48000)

Bonus: why can't I remove libavcodec.so.57

Using Synaptic, this file belongs to libavcodec-extra57 package. When I remove it, Synaptic automatically installs libavcodec57 package. If I remove it, the first one is reinstalled. Because of a lot of dependencies needing this library. If someone wants to share a quick way to fix it, I'll appreciate it.

Thank you for your time.

If you wonder, here is the long output of gcc --trace. I had another one longer with -v -Wl,-v , very similar to this but without any new mention of libavcodec.

$ g++ -Wl,--trace -L/usr/local/lib -L"/home/alejandro/Desarrollo eclipse/os1/Thirdparty" -o "os1"  ./src/Converter.o ./src/Frame.o ./src/FrameDrawer.o ./src/Initializer.o ./src/KeyFrame.o ./src/KeyFrameDatabase.o ./src/KeyFrameTriangulacion.o ./src/LocalMapping.o ./src/LoopClosing.o ./src/Map.o ./src/MapDrawer.o ./src/MapPoint.o ./src/ORBextractor.o ./src/ORBmatcher.o ./src/Optimizer.o ./src/PnPsolver.o ./src/PuntoLejano.o ./src/PuntosLejanosDB.o ./src/Sim3Solver.o ./src/System.o ./src/Tracking.o ./src/Video.o ./src/Viewer.o ./src/main.o ./src/osmap.o ./src/osmap.pb.o   -lopencv_core -lopencv_features2d -lopencv_highgui -lopencv_videoio -lopencv_imgcodecs -lopencv_imgproc -lopencv_calib3d -lpthread -lpangolin -lGL -lGLU -lDBoW2 -lg2o -lprotobuf
/usr/bin/ld: modo elf_x86_64
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o
./src/Converter.o
./src/Frame.o
./src/FrameDrawer.o
./src/Initializer.o
./src/KeyFrame.o
./src/KeyFrameDatabase.o
./src/KeyFrameTriangulacion.o
./src/LocalMapping.o
./src/LoopClosing.o
./src/Map.o
./src/MapDrawer.o
./src/MapPoint.o
./src/ORBextractor.o
./src/ORBmatcher.o
./src/Optimizer.o
./src/PnPsolver.o
./src/PuntoLejano.o
./src/PuntosLejanosDB.o
./src/Sim3Solver.o
./src/System.o
./src/Tracking.o
./src/Video.o
./src/Viewer.o
./src/main.o
./src/osmap.o
./src/osmap.pb.o
-lopencv_core (/usr/local/lib/libopencv_core.so)
-lopencv_features2d (/usr/local/lib/libopencv_features2d.so)
-lopencv_highgui (/usr/local/lib/libopencv_highgui.so)
-lopencv_videoio (/usr/local/lib/libopencv_videoio.so)
-lopencv_imgcodecs (/usr/local/lib/libopencv_imgcodecs.so)
-lopencv_imgproc (/usr/local/lib/libopencv_imgproc.so)
-lopencv_calib3d (/usr/local/lib/libopencv_calib3d.so)
/lib/x86_64-linux-gnu/libpthread.so.0
-lpangolin (/usr/local/lib/libpangolin.so)
-lGL (/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libGL.so)
-lGLU (/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libGLU.so)
-lDBoW2 (/home/alejandro/Desarrollo eclipse/os1/Thirdparty/libDBoW2.so)
-lg2o (/home/alejandro/Desarrollo eclipse/os1/Thirdparty/libg2o.so)
-lprotobuf (/usr/local/lib/libprotobuf.so)
-lstdc++ (/usr/lib/gcc/x86_64-linux-gnu/7/libstdc++.so)
/lib/x86_64-linux-gnu/libm.so.6
/lib/x86_64-linux-gnu/libmvec.so.1
/lib/x86_64-linux-gnu/libmvec.so.1
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.1)
/lib/x86_64-linux-gnu/libc.so.6
(/usr/lib/x86_64-linux-gnu/libc_nonshared.a)elf-init.oS
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
libgcc_s.so.1 (/usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.1)
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_alloc@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_free@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_is_initialized@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_close@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_init@LIBSWRESAMPLE_2' sin definir
//usr/lib/x86_64-linux-gnu/libavcodec.so.57: referencia a `swr_convert@LIBSWRESAMPLE_2' sin definir
/usr/bin/ld: se encontraron errores de enlace, se borra el ejecutable `os1'
collect2: error: ld returned 1 exit status

Also see [How to debug GCC/LD linking process for STL/C++](https://stackoverflow.com/q/11592289/608639) and [`LD_DEBUG`](http://man7.org/linux/man-pages/man8/ld.so.8.html) man page. — jww, Feb 02 '19 at 15:29

score 2 · Accepted Answer · answered Feb 02 '19 at 20:17

What is almost certainly happening is that one of the shared libraries you are loading in turns needs another shared library. This is encoded into the shared library itself in the ELF header. Use readelf -d on the shared library to see this. Look for NEEDED lines. ld will process libs it finds this way, but they don't appear in the output of --trace.

I don't know of a way to automatically find the source, but try readelf on the libraries that do appear in your trace and you should find one that needs libavcodec, or needs a library that in turns needs libavcodec, etc.

When you do find the NEEDED line, pay careful attention what exactly is in it. Is it libavcodec.so, or libavcodec.so.57? Is it just a file name or does have it have an absolute path? This affects what the linker will find when it searches for it.

For the linker search path, look at the documentation for the rpath-link option to ld. What is the first file (likely a symlink) named libavcodec.so in that path? Keep in mind the linker search for what appears in the NEEDED line. It's not going to shorten libavcodec.so.57 into libavcodec.so and search for the latter.

score 1 · Answer 2 · answered Feb 03 '19 at 00:08

1

After @TrentP answer, it was clear there wasn't an easy way to do it, so I did as he suggested, the hard way, I looped over all shared objects recursively looking for dependencies. I used ldd -r instead of readelf. ldd -r lists dependencies recursively (direct and indirect).

In a text file I put the full path list of shared object that appeared in gcc output. Then run:

while read -r line; do echo "Library $line has these dependencies:\n $(ldd -r $line)"; done <textfile.txt

I found libavcodec.so.57 in the listed output, and detected which shared object needed it.

answered Feb 03 '19 at 00:08

Alejandro Silvestri

3,706
31
43

1

The recursive feature of `ldd -r` is very handy when it works, but there are a couple issue that one could run into. First, you can't use it when cross-compiling, as the library needs to be something that can actually be loaded by the system's dynamic loader. The other is the search path `ldd` uses when finding libraries is not the same as what `ld` will use when trying to link. So what `ldd` found (right side, vs what it looked for on the left) might not be correct, and what it recursively found because of that might not also be incorrect. – TrentP Feb 27 '19 at 00:20

score -2 · Answer 3 · answered Feb 02 '19 at 15:05

-2

There are two ways to approach this:

Read the Manual; always a good idea.
Install a dependency manager. I use MacPorts, but there are a handful of different ones out there. They have a database of libraries that they manage, and when you install or build one of their libraries the manager will also install or build all of the libraries that the one you're installing depends on if they're not already present, and the ones that they depend on, etc.

answered Feb 02 '19 at 15:05

Pete Becker

74,985
8
76
165

I appreciate your dedication, I don't think it really answer my question. I want to debug ld process. – Alejandro Silvestri Feb 02 '19 at 16:27

How to trace the need of a library when linking?

3 Answers3