This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld linking behaviour


Edward Peschko <horos11@gmail.com> writes:

> When I link with a shared library, for example:
>
>  env LD_RUN_PATH="/usr/lib" /usr/bin/gcc -shared -fPIC
> -L/usr/local/lib -Wl,-rpath,/home/y/lib Libconfig.o -o
> blib/arch/auto/Conf/Libconfig/Libconfig.so -L/usr/lib -L/usr/local/lib
> /usr/lib/libconfig.so
>
> the ld command follows the version, and links to the specific version
> of the library, not the library itself. An ldd dump shows :
>
> prompt% ldd blib/arch/auto/Conf/Libconfig/Libconfig.so
>         linux-gate.so.1 =>  (0xffffe000)
>         libconfig.so.8 => /usr/lib/libconfig.so.8 (0xf7fe2000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xf7eb7000)
>         /lib/ld-linux.so.2 (0x56555000)
>
>
> How can I make it so that the ld command instead links to the
> libconfig.so library itself (so that if a newer, binary compatible,
> version of libconfig comes out it can use it transparently)?

The version number that you see there comes from the DT_SONAME dynamic
tag in the library.  By convention, all binary compatible versions of
libconfig.so.8 will have an SONAME of libconfig.so.8.  This is
normally implemented by providing a series of libraries
libconfig.so.8.1, libconfig.so.8.2, etc., with a symlink
libconfig.so.8 to the most recent one.  Then, if there is a binary
incompatible change, the new symlink will be libconfig.so.9.

So, if libconfig.so.8 follows this pattern, you do not want to do what
you are asking.  If libconfig.so.8 does not follow this pattern, then
they should not use a DT_SONAME tag.  In short, this is not a change
which should be made in the linker.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]