From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D3F8F1396D0 for ; Wed, 20 Sep 2017 09:26:14 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5692B1FC094; Wed, 20 Sep 2017 09:26:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0D5EF1FC06C for ; Wed, 20 Sep 2017 09:26:08 +0000 (UTC) Received: from [10.255.42.244] (public-gprs410564.centertel.pl [37.47.235.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id A1D2133C6B6; Wed, 20 Sep 2017 09:26:05 +0000 (UTC) Date: Wed, 20 Sep 2017 11:25:59 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <7041474.d5JyQIntDE@porto> References: <1577962.20ZSkpDzGI@porto> <13cb1de2-e252-13d9-fa47-1133d85b42e2@gentoo.org> <7041474.d5JyQIntDE@porto> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [gentoo-dev] Re: glibc-2.26 and changes with SunRPC, libtirpc, ntirpc, libnsl (NIS and friends), ... To: gentoo-dev@lists.gentoo.org,"Andreas K. Huettel" From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= Message-ID: <44D1A540-4491-4C41-BD84-24FF470CB3F9@gentoo.org> X-Archives-Salt: edb5436c-cb3c-40fb-8e6f-4487ffc212de X-Archives-Hash: c6b9bd7a5cba7ecd03efcfcc1b587852 Dnia 20 wrze=C5=9Bnia 2017 10:23:42 CEST, "Andreas K=2E Huettel" napisa=C5=82(a): >Am Dienstag, 19=2E September 2017, 22:38:17 CEST schrieb Luca Barbato: >> > REQUIRED_USE=3D"^^ ( sunrpc libtirpc ntirpc )" >> > If rpc support is optional with useflag rpc, then this becomes >> > REQUIRED_USE=3D"rpc? ( ^^ ( sunrpc libtirpc ntirpc ) )" >> >=20 >> > Since the three options are coinstallable I see no problems with a >package >> > only supporting a subset, but I have no clue how this interacts at >> > runtime=2E >>=20 >> If they aren't ABI-compatible you would expect explosions once you >link >> two libraries linked to the two different implementation (assuming >they >> aren't macro-mangling everything)=2E > >Yep=2E So, apart from requiring "use the same implementation everywhere", >i=2Ee=2E=20 >set the flag globally, and stating "if you micromanage, you have to >contain=20 >the explosions yourself" - is there anything else we can realistically >do? dev-libs/foo[sunrpc=3D,tirpc=3D=2E=2E=2E]?=20 > >> We could check if the other libc could be switched to the external >> provider and play the lazy card and just always force an external >> implementation=2E > >Two or three implementations doesnt make that much of a difference >anymore=2E=2E=2E --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone)