Date: Tue, 13 Feb 2001 11:41:41 -0800 From: Peter Wemm <peter@netplex.com.au> To: Warner Losh <imp@harmony.village.org> Cc: Dag-Erling Smorgrav <des@ofug.org>, "Alexander N. Kabaev" <ak03@gte.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Proposal on shared libs version values. Message-ID: <200102131941.f1DJffU66659@mobile.wemm.org> In-Reply-To: <200102131717.f1DHHNW39519@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: > In message <xzppugmv7je.fsf@flood.ping.uio.no> Dag-Erling Smorgrav writes: > : Hmm? I must have seriously misunderstood all the discussions that went > : on around E-day. > > What I had thought happened was that ld just uses the symbolic link > blindly. However, I just tried it on my system: > > cd /usr/lib > cp libc.so.4 libc.so.4.1 > ln -sf libc.so.4.1 libc.so > ldconfig -R > ldconfig -r | grep libc.so.4 > 33:-lc.4 => /usr/lib/libc.so.4 > > So it does look like it has to be a single number. Forget what I said > about 5.1 being a viable option. ldconfig -r is fake anyway. ld(1) does not use it. ldconfig -r exists only for the benefit of 3rd party scripts. > My OpenBSD box does have minor numbers appended, but they also have > hacks in their ld to cope. In order to inject facts into the discussion, consider: peter@mobile[11:22am]~src-161> objdump --all-headers /usr/lib/libc.so.5 ... Dynamic Section: SONAME libc.so.5 ... peter@mobile[11:22am]~src-162> ls -l /usr/lib/libc.so lrwxr-xr-x 1 root wheel 9 Dec 22 15:35 /usr/lib/libc.so@ -> libc.so.5 The way it works is this: - ld opens libc.so (via the symlink, it can be a hard link or copy even) - it sees the embedded DT_SONAME in the object. - the DT_SONAME is what gets copied to the DT_NEEDED of the program being linked. You had better hope they are the same file. :-) - at runtime, ld-elf.so.1 searches for "libc.so.5" by name because that is what was copied. If DT_SONAME had "libc.so.5.1", then that is what ld would copy to the application and ld-elf.so.1 will look for "libc.so.5.1". ldconfig has *nothing* to do with it except provide a list of directories for ld-elf.so.1 to look in, besides the hard coded /usr/lib. peter@mobile[11:27am]~src-166> strings /var/run/ld-elf.so.hints Ehnt /usr/lib:/usr/lib/compat:/usr/X11R6/lib:/usr/local/lib (that's "Elf Hint") Note there are no pathnames, version numbers, anything. ldconfig -r is simply doing a readdir() of /usr/lib and generating a fake a.out lookalike output. It can be easily fixed to deal with libc.so.5.1 if that is desirable. When libc is built, we could link it with "-h libc.so.5-13-Feb-2001" and that is what all applications will depend on (so it had better exist). At link time, all ld looks at is what is embedded in whatever it opens by opening "libc.so" and records the dependency embedded in there. Nothing would check if "libc.so.5-13-Feb-2001" actually existed until you tried to run the application that depended on it. This is not directed at anybody in particular, just an attempt to get some concrete facts and common understanding into the discussion. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102131941.f1DJffU66659>