0

I'm on an Ubuntu 22.04 system and I'm working with C language and libraries.

I know (from different books, included "The Linux Programming Interface" by Kerrisk) that this algorithm is used when looking for runtime shared libraries locations (I just omitted the preloaded libraries for the sake of simplicity):

When RUNPATH field is specified (i.e. DT_RUNPATH is non-empty)

  1. LD_LIBRARY_PATH
  2. runpath (DT_RUNPATH field)
  3. ld.so.cache
  4. default library paths (/lib and /usr/lib)

In the absence of RUNPATH (i.e. DT_RUNPATH is empty string)

  1. RPATH
  2. LD_LIBRARY_PATH
  3. ld.so.cache
  4. default library paths (/lib and /usr/lib)

The problem is that most books say that generally speaking the default library paths are /lib and /usr/lib but they don't mention how I can get the exact default library paths for my system.

  1. What command can I use on my Ubuntu 22.04 system to get the exact default library path?
8
  • 1
    Your question is a bit confusing - you ask about "runtime shared libraries" but also about headers (which are not involved at all at runtime - only during compilation). Commented Jan 22 at 14:58
  • @steeldriver, why is it confusing ? I think it is super clear like a blue cloudless summer sky. What I'm asking for is the default runtime library location paths and then the default headers include paths...the fact that the headers are just a preprocessing stuff doesn't mean anything
    – Kode1000
    Commented Jan 22 at 15:26
  • @muru, I don't think it should be asked in different posts since here we are talking about DEFAULT PATHS that are related to runtime libraries and headers. Now I think headers are deeply related to libraries ? Don't they ?
    – Kode1000
    Commented Jan 22 at 15:47
  • 1
    They are, but the things that use those default paths are unrelated, might not even be in the same system, and even in the same system might have completely unrelated values. In fact, isn't that why you had to ask about headers in addition to libraries at all?
    – muru
    Commented Jan 22 at 15:49
  • @muru, I didn't say they use the same default paths...Anyway feel free to shed some light to it if you are an experienced and seasoned ubuntu guy. I would be helpful for who like me wanna know these answers.
    – Kode1000
    Commented Jan 22 at 15:51

3 Answers 3

1

You can use ld, which can show system library paths and also your user's defined library paths.

ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012

If ld does not exists in your system you may install it by

sudo apt install binutils

Note: It might be a bit heavy however you will get exact results, but in your case you must be already installed it.

2
  • ld would resolve the link time dependencies (i.e. when the executable is built) I think - isn't it ld.so / ld.so.conf / ld.so.conf.d that determine the runtime library search path? Commented Jan 22 at 15:03
  • @steeldriver I think they both same if the target pc and build pc is same
    – obayhan
    Commented Jan 23 at 7:05
1

Ubuntu uses glibc, and glibc supports some debugging options which can be of help here. From man ld.so:

LD_DEBUG (since glibc 2.1)
      Output verbose debugging information about operation of the  dynamic  linker.   The
      content  of  this variable is one of more of the following categories, separated by
      colons, commas, or (if the value is quoted) spaces:

      help        Specifying help in  the  value  of  this  variable  does  not  run  the
                  specified  program,  and displays a help message about which categories
                  can be specified in this environment variable.

      all         Print all debugging information  (except  statistics  and  unused;  see
                  below).
      bindings    Display information about which definition each symbol is bound to.
      files       Display progress for input file.
      libs        Display library search paths.
      reloc       Display relocation processing.
      scopes      Display scope information.
      statistics  Display relocation statistics.
      symbols     Display search paths for each symbol look-up.
      unused      Determine unused DSOs.
      versions    Display version dependencies.

And in addition, you can suppress the cache using:

--inhibit-cache
      Do not use /etc/ld.so.cache.

With that, all you need to do is ensure that LD_LIBRARY_PATH isn't set, and find a binary that doesn't mess with RPATH or RUNPATH. For example:

env -u LD_LIBRARY_PATH LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --inhibit-cache /bin/true # on amd64
env -u LD_LIBRARY_PATH LD_DEBUG=libs /lib/ld-linux-armhf.so.3 --inhibit-cache /bin/true # on armhf
5
  • ok so If I run "env -u LD_LIBRARY_PATH LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --inhibit-cache /bin/true" I should get only the default library paths ? I've tried but it looks a bit messy
    – Kode1000
    Commented Jan 22 at 16:29
  • @Kode1000 yes, apparently that is expected. It seems glibc's dynamic linker takes your default paths (/lib, /usr/lib, or /lib64, /usr/lib64 - these are mentioned in the manpage), and then tacks on a bunch of feature/platform-specific paths, some of which can be obsolete, resulting in a combinatorial explosion of the final, actual search paths. See, e.g., linaro-toolchain.linaro.narkive.com/jMRT4LTL/…
    – muru
    Commented Jan 22 at 16:41
  • Yes, even after excluding those, the actual search path is messy, because of the platform and feature specific paths being added on. Note that these are also applied to RPATH and RUNPATH, so if you had an executable that had one of those set, the result could have been doubly messy.
    – muru
    Commented Jan 22 at 16:45
  • but couldn't I just examine "/etc/ld.so.conf.d/*.conf" to see the default library paths instead of doing all this filtering ? I've heard that the loader uses this configuration files...Is it true ?
    – Kode1000
    Commented Jan 22 at 16:51
  • Not directly. Those files are used to construct the cache, and you'll notice that edits to them don't take effect until you update the cache using ldconfig (and we're ignoring the cache anyway)
    – muru
    Commented Jan 22 at 16:59
0

Assuming you're on amd64, you can execute /lib64/ld-linux-x86-64.so.2 --help, the bottom sections will give you what you're looking for:

Shared library search path:
  (libraries located via /etc/ld.so.cache)
  /lib/x86_64-linux-gnu (system search path)
  /usr/lib/x86_64-linux-gnu (system search path)
  /lib (system search path)
  /usr/lib (system search path)

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4 (supported, searched)
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

You can use similar approaches for other arches, the specific name and location of the linker will likely be different though.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .