From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 17 Nov 2009 04:10:27 +0300 From: Alexey Tourbin To: ALT Linux Team development discussions Message-ID: <20091117011027.GZ10659@altlinux.org> Mail-Followup-To: ALT Linux Team development discussions References: <1258101392.3733.55.camel@marsh.altlinux.lan> <200911160047.42541.ledest@gmail.com> <20091115231156.GS10659@altlinux.org> <200911160143.52687.ledest@gmail.com> <20091116001642.GT10659@altlinux.org> <20091116002722.GB32432@wo.int.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0ywUhQCikZ2Y3PNw" Content-Disposition: inline In-Reply-To: <20091116002722.GB32432@wo.int.altlinux.org> Subject: Re: [devel] symbols into dependencies X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 01:10:29 -0000 Archived-At: List-Archive: List-Post: --0ywUhQCikZ2Y3PNw Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 16, 2009 at 03:27:23AM +0300, Dmitry V. Levin wrote: > On Mon, Nov 16, 2009 at 03:16:42AM +0300, Alexey Tourbin wrote: > [...] > > =E4=C1, "=CB=CF=CE=C3=C5=D0=D4=D5=C1=CC=D8=CE=C1=D1" =CD=CF=C4=C5=CC=D8= =C9=CD=C5=CE=CE=CF =D4=C1=CB=C1=D1 -- =CF=D4=D3=CC=C5=D6=C9=D7=C1=D4=D8 = =D3=C9=CD=D7=CF=CC=D9 > > =D7=CE=D5=D4=D2=C9 =D3=CF=CE=C5=CA=CD=C1. > >=20 > > Provides: (libfoo.so.1;foo_sym1,foo_sym2,foo_sym3,...) > > Requires: (libfoo.so.1;foo_sym1,foo_sym2) >=20 > To match ELF semantics, we have to implement smth more complicated: >=20 > libfoo Provides(ELF): foo_sym1,foo_sym2,... > libbar Provides(ELF): bar_sym1,bar_sym2,... > client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,... So what is your model here? Providing global symbols (without soname context) is wrong: until the library is open and mmap'd, a symbol means nothing. It is just a name clash until then. A collision. So, to match ELF semantics, which is to allow symbols be moved across the libraries, the model can be like this: libfoo Provides(ELF): libfoo:foo_sym1,foo_sym2,... libbar Provides(ELF): libbar:bar_sym1,bar_sym2,... client Requires(ELF): libfoo,libbar:foo_sym1,...,bar_sym1,... To resolve the Requires dependency is then to check that each symbol foo_sym1,...,bar_sym1,... can be resolved into at least one _required_ library. Or, in terms of sets, requires set should be a subset of the union of provides sets, with the union calculated for the appropriate sonames. However, if we consider "tegent problem" again, we have to admit that this whole blasted thing still does not provide close-enough ELF semantics. The problem is that "tgetent" was part of libncurses, and then libtinfo emerged as a separate library. And older binaries are not linked with libtinfo, so it won't be possible to resolve their undefined symbols against the _required_ libraries. Look, the next step in improving the model is to implement recursive symbols lookup (i.e. "passing on" of symbols down the river). Now, if you think about this a few more minutes, you have to recognize that we are actually going to reimplement some parts of dynamic linker within rpm dependency mechanism. > And there is also symbol versioning that makes the picture even more > complex. So, to follow ELF semantics the way dynamic linker does, you simply end up with reimplementing certain parts of the dynamic linker. And not only the linker, but special kind of dependencies are required to mimic certain ELF data structures (e.g. set-union). Which is indeed complicated. I argue that we do not follow ELF semantics that much closely. The whole thing should be boiled down to a much simpler model. --0ywUhQCikZ2Y3PNw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksB+AMACgkQfBKgtDjnu0Z9kQCfXmJR8489FVyIaLtOp4jt0nW/ jQAAoNIvTvztDtdSgFNFnTh8G/REEYdy =WlLA -----END PGP SIGNATURE----- --0ywUhQCikZ2Y3PNw--