1. 18

  2. 6

    Rather than manually stepping through each of the dependencies to print dependencies of dependencies, I like to use lddtree[0].

    1. https://codeyarns.com/2015/12/16/how-to-view-hierarchy-of-shared-library-dependencies-using-lddtree/
    1. 3

      Another method of reading dependencies would be to use readelf(1) tool (from binutils), i.e.:

      ❯ readelf -d /bin/ls
      Dynamic section at offset 0x20a98 contains 24 entries:
        Tag        Type                         Name/Value
       0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
       0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

      But it will only show dependencies of selected file, not dependencies of their dependencies (so, it’s not recursive).

      Good thing about readelf is that it doesn’t need to map the executable into memory in order to extract the data, it just interprets ELF structure to extract dependency info.

    2. 2

      Use SDL_GL_GetProcAddress instead of linking to libGL directly (for that matter, don’t use GLU or GLEW)

      Do use libepoxy if you’re not using SDL though.

      1. 1

        AIUI, the glxgears list is a flaw of all GNU linkers. glxgears doesn’t actually need those dependencies, libGL does. It does dynamically link against them (see ldd libGL.so), and that should be fine. But the compile-time linker croaks, and there you go.