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 757BA1396D0 for ; Fri, 11 Aug 2017 08:14:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3833D1FC016; Fri, 11 Aug 2017 08:14:50 +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 E48D6E0D82 for ; Fri, 11 Aug 2017 08:14:49 +0000 (UTC) Received: from sf (host86-155-194-189.range86-155.btcentralplus.com [86.155.194.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: slyfox) by smtp.gentoo.org (Postfix) with ESMTPSA id 41236341A68 for ; Fri, 11 Aug 2017 08:14:48 +0000 (UTC) Date: Fri, 11 Aug 2017 09:14:42 +0100 From: Sergei Trofimovich Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc Message-ID: <20170811091442.0b13c595@sf> In-Reply-To: References: <20170808155322.16552-1-slyfox@gentoo.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=pgp-sha1; boundary="Sig_/Natm1n0RVsf2Hg=WxNIHkcY"; protocol="application/pgp-signature" X-Archives-Salt: 416788f7-247f-453e-aa0a-d8b7fdea4853 X-Archives-Hash: 353b2e4b0074824a3ab631b2bc107d8a --Sig_/Natm1n0RVsf2Hg=WxNIHkcY Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 10 Aug 2017 21:41:24 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted: >=20 > > The failure happens when live glibc-9999 ebuild is installed: > > * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so * ERROR: > > sys-libs/glibc-9999::gentoo failed: > > * add those ldscripts > >=20 > > The problem here is how upstream glibc version is detected: > > dosym ../../$(get_libdir)/libm-${PV}.so > > $(alt_usrlibdir)/libm-${PV}.so > >=20 > > Change to use 'version.h' to pick upstream version. =20 >=20 > Interesting that it's libm. See bug #627378 >=20 > https://bugs.gentoo.org/627378 >=20 > ... where ~arch glibc-2.25-r2 (apparently) allows the symlink creation=20 > line above to clobber the original library binary, in usr merge (/lib64=20 > and /usr/lib64 are the same dir) cases, or at least when /usr -> . (aka=20 > "reverse" usr merge). >=20 > Comment #4 says it's not new code, thus the "(apparently)" above What is your point there? I'm afraid I lost you. (being an eclass) All the glibc ebuilds do this same libm symlinking. Live ebuild was broken for quite a while because upstream never installed libm-9999.a files. > but=20 > perhaps it's acting differently now due to the recent migration away from= =20 > eblits? What I know for sure is that the upgrade broke my system until I= =20 > manually copied the libm binary from the binpkg back into place. You can check if it's a new breakage by setting up a chroot: - with your '/usr -> .' symlinks set - with pre-eblits glibc portage tree by rewinding git ::gentoo - install any glibc version from there to chech if the breakage is new I suspect it's not a new breakage. Because glibc does not check symlink state on a live system (and it should not). portage does peform merge into live system phase and writes two files into the same path. portage would be a better place to detect symlink collision and save your s= ystem. I think this discussion belongs to https://bugs.gentoo.org/627378 --=20 Sergei --Sig_/Natm1n0RVsf2Hg=WxNIHkcY Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSZKa0VG5avZRlY01hxoe52YR/zqgUCWY1ncgAKCRBxoe52YR/z qjRfAJ0RMT4B/nQ06o/4xfL6SPtncy3w4gCfY66d37Zc0GOrgB977lCBcamxosE= =US44 -----END PGP SIGNATURE----- --Sig_/Natm1n0RVsf2Hg=WxNIHkcY--