title: Is there a way to set the elf NEEDED field at link time?
body: <p>Given a executable such that:</p>
  
  <pre><code>&gt;objdump -x someprog | grep c++
  NEEDED               libstdc++.so.6
  </code></pre>
  
  <p>I want to change the requirement to the full version (including the minor version and patch level):</p>
  
  <pre><code>&gt;objdump -x someprog | grep c++
  NEEDED               libstdc++.so.6.0.22
  </code></pre>
  
  <p>I know of two ways to do this:</p>
  
  <ol>
  <li>create a dummy library as per this question (<a href="https://stackoverflow.com/questions/25979778/forcing-or-preventing-use-of-a-particular-minor-version-of-libstdc">Forcing or preventing use of a particular minor version of libstdc++</a>)</li>
  <li>use patchelf</li>
  </ol>
  
  <pre>
      >patchelf --add-needed libstdc++.so.6.0.22 someprog
      >objdump -x someprog | grep c++
      NEEDED               libstdc++.so.6
      NEEDED               libstdc++.so.6.0.22
  </pre>
  
  <p>(I haven't figured out a working command line for --replace-needed)</p>
  
  <p>Both of these feel like hacks to me. <strong>Is there a way to achieve the same at compile or link time using appropriate -Wl flags to gcc?</strong></p>
  
  <p>Ideally I want to avoid using -nostdlib as that requires I specific not just libstd++ but libc and everything else for which I do want standard versions.</p>
  
  <p>For a regular library just linking to the specific version is enough for libstdc++ it is not (or rather I suspect -stdlib overrides subsequent fully qualified names I provide).</p>
  
  <p><em>Background</em>: I have executables which require a later version of <code>libstdc++</code> than is installed on the system. Unfortunately the installed version could be the same major version and if so <code>ld</code> will happily use the system version as it matches the <em>soname</em> <code>libstdc++.so.6</code></p>
  
  <p>I prefer not to statically link as I actually want to install many small programs sharing the same C++ runtime and this would bloat the installation considerably.</p>
  
  <hr>
  
  <p>Some information about my (the) library search path is available here:</p>
  
  <blockquote>
    <p>ld --verbose | grep SEARCH_DIR 
    SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");</p>
  </blockquote>
  
  <p>It is clear in my case that /usr/lib64 is being searched before the RPATH of the executable which is:</p>
  
  <pre><code>&gt;objdump -x /opt/foo/bin/bar | grep PATH
  RPATH                $ORIGIN/../lib64/private:$ORIGIN/../lib64:$ORIGIN/
  </code></pre>
  
  <p><code>man ld.so</code> suggests the search order should be:</p>
  
  <blockquote>
    <p>If a library dependency does not contain a slash, then it is searched
    for in the following order:
    </p>
  </blockquote>
  
  <pre><code>   o  (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.  Use of DT_RPATH is deprecated.
  
     o  Using the environment variable LD_LIBRARY_PATH.  Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored.
  
     o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.
  
     o  From the cache file /etc/ld.so.cache, which contains a compiled list of candidate libraries previously found in the augmented library path.  If, however, the binary was linked with the  -z  node‐
        flib linker option, libraries in the default library paths are skipped.  Libraries installed in hardware capability directories (see below) are preferred to other libraries.
  
     o  In the default path /lib, and then /usr/lib.  If the binary was linked with the -z nodeflib linker option, this step is skipped.
  </code></pre>
  
  <p>
  Similarly <a href="https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf" rel="nofollow noreferrer">https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf</a></p>
  
  <p>Both seem to be trumped by actual usage but in fact this is not the case.
  the needed is looking for symbolic links:</p>
  
  <pre><code>&gt;LD_LIBRARY_PATH= LD_DEBUG=libs ldd /opt/foo/bin/bar
   21720:     find library=libstdc++.so.6 [0]; searching
   21720:      search path=/opt/foo/bin/../lib64/private:/opt/foo/bin/../lib64:/opt/foo/bin                (RPATH from file /opt/foo/bin/bar)
   21720:       trying file=/opt/foo/bin/../lib64/private/libstdc++.so.6
  </code></pre>
  
  <p>This is an interaction with another question I had <a href="https://stackoverflow.com/questions/45213145/install-shared-imported-library-with-necessary-links">install shared imported library with necessary links</a> where the suggestion was that the links are not required.
  They clearly <em>are</em> required if you do not specify the full semantic version.</p>