Date: Tue, 17 Jun 2003 11:30:32 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Dan Nelson <dnelson@allantgroup.com> Cc: Joe Kelsey <joek@mail.flyingcroc.net> Subject: Re: Tools to modify shared libraries Message-ID: <20030617183032.GA1375@dhcp01.pn.xcllnt.net> In-Reply-To: <20030617180858.GL64929@dan.emsphone.com> References: <3EEE4717.2090409@mail.flyingcroc.net> <1055804020.79093.2.camel@rushlight.kf8nh.apk.net> <3EEF19D5.9040706@mail.flyingcroc.net> <20030617154208.GA584@dhcp01.pn.xcllnt.net> <3EEF3883.1080500@mail.flyingcroc.net> <20030617160141.GB584@dhcp01.pn.xcllnt.net> <20030617130236.7c683e4c.ak03@gte.com> <20030617174834.GA1012@dhcp01.pn.xcllnt.net> <20030617180858.GL64929@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030617183032.GA1375>