https://sourceware.org/bugzilla/show_bug.cgi?id=23295
Cary Coutant <ccoutant at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Cary Coutant <ccoutant at gmail dot com> ---
You're missing the symbolic links from libname.so -> libname.so.X.Y.
When the linker searches for -lname, it looks for a file named libname.a or
libname.so. In the case of a versioned shared library, libname.so will be a
symbolic link to the latest (or default) version of the library, say
libname.so.3.2. That library should have a DT_SONAME tag in its dynamic table
that records the real name, libname.so.3.2. The linker then records that
"soname" in the DT_NEEDED entry of the file it's generating, so that the
dynamic loader will find the correct version of the library, even if a newer
version eventually supersedes it later.
In some versioning schemes that use a major/minor (or even a three-level)
scheme, a newer minor version is allowed to supersede an older library with the
same major version, even for binaries that have been linked against the older
minor version. To support this scheme, there would be a symbolic link from
libname.so to libname.so.3, and libname.so.3 will itself be a symbolic link to
libname.so.3.2. The DT_SONAME field would then record just "libname.so.3"
instead of the full name. Later, if libname.so.3.3 is released, the symbolic
link from libname.so.3 would be updated to point to libname.so.3.3, and the
dynamic loader will then load the newer version without having to relink the
program.
The naming of the actual versioned libraries is by convention only -- they
could be named libname-3.2.so, for example. They could even reside in a
different directory. All that matters is that the symbolic link points to it,
and the DT_SONAME field provides the filename by which the dynamic loader can
find it.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
