I&#x27;m not sure <i>exactly</i> what you&#x27;re referring to; the -soname ld option is used to set the value internally to a library that that library is known as <i>when building a library</i>, and is used as part of ld.so at runtime to find the appropriate .so file to run-time dynamically link against.<p>The issue I described is during build time of a program that uses a shared library.  Given this list of available libraries:<p><pre><code>    lrwxrwxrwx     21 Apr 20  2011 libevent.so.2 -&gt; libevent.so.2.1.3
    -rwxr-xr-x 106656 Aug 20  2010 libevent.so.2.1.3
    lrwxrwxrwx     21 Jun  3  2012 libevent.so.5 -&gt; libevent.so.5.1.3
    -rwxr-xr-x 277760 Jun  3  2012 libevent.so.5.1.3
    lrwxrwxrwx     21 Jun  3  2012 libevent.so -&gt; libevent.so.5.1.3
</code></pre>
there is no way to use the -levent option to gcc or ld to specify you want to link against libevent.so.2.  If you just give it -levent, it will <i>always</i> link against libevent.so, which as these symlinks show, is pointing to libevent.so.5.1.3 (which is actually libevent-2.0) — this is documented in the ld man page under the -l option as for how &quot;namespec&quot; is resolved.  Unfortunately, the APIs are different between 1.4 and 2.0, which is why this is necessary: not everyone who uses libevent has updated their code to use the new libevent API, yet we still want to use that software.<p>The &quot;fix&quot; is to move some kind of &quot;logical&quot; version number into the filename (although, which is &quot;logical&quot; and which is &quot;physical&quot; becomes ambiguous), like so:<p><pre><code>    $ ll libevent[-.]*
    lrwxrwxrwx     21 Apr 20  2011 libevent-1.4.so.2 -&gt; libevent-1.4.so.2.1.3
    -rwxr-xr-x 106656 Aug 20  2010 libevent-1.4.so.2.1.3
    lrwxrwxrwx     21 Jun  3  2012 libevent-2.0.so.5 -&gt; libevent-2.0.so.5.1.3
    -rwxr-xr-x 277760 Jun  3  2012 libevent-2.0.so.5.1.3
    lrwxrwxrwx     21 Jun  3  2012 libevent.so -&gt; libevent-2.0.so.5.1.3
</code></pre>
so you can obtain a linkage against 2.1.3 by specifying -levent-1.4.  This &quot;encourages&quot; one to use the 2.0 API by using libevent-2.0 if you specify a bare -levent.  The -devel package with the header files will usually be for the latest version anyway, complicating the build process on a single machine with both libraries available (you&#x27;d have to build against a local&#x2F;non-system-include-tree copy of 1.4&#x27;s headers).  I know some redhat&#x2F;centos packages do do this (which is why I have both libevent-1.4 and libevent-2.0 on my system, but I don&#x27;t know how those packages&#x27; specifically do this.<p>The other way around this is to explicitly link against the full path &#x2F;usr&#x2F;lib64&#x2F;libevent.so.2.1.3 <i>and not</i> use the -l option at all for this library.  This works in part because of the -soname option you pointed out.  While this works, and produces the same output if one <i>could</i> use -l to select the correct library file, most of the build tools we have at our disposal prefer to use -l to select libraries at build time rather than full paths (because if you use -l to select a system installed library, ld does the work of searching its cache and standard paths for you; however, you can get around this with the :filename version of namespec to the -l option).  This means that some programs&#x27; build processes would be different on systems that have only the old, only the new, or both libraries on the system, and a bunch of programs build processes might need to change once the new version comes out.<p>The problem here is that -l only lets you specify the name, not the version to link against, under the (arguably well-founded) assumption that old versions should not be used for new builds but you need to keep them around for already-built programs to link against (dynamically, at run time).