Tools to modify shared libraries

Marcel Moolenaar marcel at xcllnt.net
Tue Jun 17 11:30:58 PDT 2003


On Tue, Jun 17, 2003 at 01:08:58PM -0500, Dan Nelson wrote:
> 
> Dependencies can change after a program is linked, though.

Only dependencies on the implementation, not the interface.

> How about
> the contrived case of a program needing the openpty function, so -lutil
> is linked in.  Then 6 months later openpty is moved to libc, making the
> dependency on libutil unneeded.  The end result is the same as if a new
> program is unnecessarily linked with -lutil, but cannot be "fixed" with
> ld because at the time it was linked, the first program actually did
> need libutil.

It's a bad example. The moment you remove openpty() from libutil,
you change its interface and thus are required to bump the library
version. The binary that was linked against libutil at the time
openpty() was still part of its interface will not have a dependency
on the new libutil, but on the old libutil by virtue of the version
information.

Likewise, the addition of openpty() to libc requires a version bump
in its strictest sense (both backward *and* forward compatibility),
but is in practice not done because we don't guarantee forward
compatibility.

Hence, DT_NEEDED is still accurate, but due to practical reasons of
not bumping the libc version, openpty() can now be found in both
libraries and the first occurrence is taken. This can abstractly
speaking be libc, which would then in theory make the dependency on
libutil unnecessary. This however is not a concern for the linker,
as it is a glitch caused beyond the scope of the linker (ie our
choice to not provide forward compatibility in combination with
our choice to be sloppy).

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net


More information about the freebsd-questions mailing list