[gentoo-dev] [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[gentoo-dev] [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Sergei Trofimovich]

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

The problem here is how upstream glibc version is detected:
    dosym ../../$(get_libdir)/libm-${PV}.so $(alt_usrlibdir)/libm-${PV}.so

Change to use 'version.h' to pick upstream version.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
---
 eclass/toolchain-glibc.eclass | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index 1d6a54a37f1..83d6293c6cb 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -1138,10 +1138,14 @@ toolchain-glibc_do_src_install() {
 		cp -a elf/ld.so "${ED}"$(alt_libdir)/$(scanelf -qSF'%S#F' elf/ld.so) || die "copying nptl interp"
 	fi
 
+	# Normally real_pv is ${PV}. Live ebuilds are exception, there we need
+	# to infer upstream version:
+	# '#define VERSION "2.26.90"' -> '2.26.90'
+	local upstream_pv=$(sed -n -r 's/#define VERSION "(.*)"/\1/p' "${S}"/version.h)
 	# Newer versions get fancy with libm linkage to include vectorized support.
 	# While we don't really need a ldscript here, portage QA checks get upset.
-	if [[ -e ${ED}$(alt_usrlibdir)/libm-${PV}.a ]] ; then
-		dosym ../../$(get_libdir)/libm-${PV}.so $(alt_usrlibdir)/libm-${PV}.so
+	if [[ -e ${ED}$(alt_usrlibdir)/libm-${upstream_pv}.a ]] ; then
+		dosym ../../$(get_libdir)/libm-${upstream_pv}.so $(alt_usrlibdir)/libm-${upstream_pv}.so
 	fi
 
 	# We'll take care of the cache ourselves
-- 
2.14.0

[gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Duncan]

Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted:

> 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
> 
> The problem here is how upstream glibc version is detected:
>     dosym ../../$(get_libdir)/libm-${PV}.so
>     $(alt_usrlibdir)/libm-${PV}.so
> 
> Change to use 'version.h' to pick upstream version.

Interesting that it's libm.  See bug #627378

https://bugs.gentoo.org/627378

... where ~arch glibc-2.25-r2 (apparently) allows the symlink creation 
line above to clobber the original library binary, in usr merge (/lib64 
and /usr/lib64 are the same dir) cases, or at least when /usr -> . (aka 
"reverse" usr merge).

Comment #4 says it's not new code, thus the "(apparently)" above, but 
perhaps it's acting differently now due to the recent migration away from 
eblits?  What I know for sure is that the upgrade broke my system until I 
manually copied the libm binary from the binpkg back into place.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Sergei Trofimovich]

[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

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:
> 
> > 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
> > 
> > The problem here is how upstream glibc version is detected:
> >     dosym ../../$(get_libdir)/libm-${PV}.so
> >     $(alt_usrlibdir)/libm-${PV}.so
> > 
> > Change to use 'version.h' to pick upstream version.  
> 
> Interesting that it's libm.  See bug #627378
> 
> https://bugs.gentoo.org/627378
> 
> ... where ~arch glibc-2.25-r2 (apparently) allows the symlink creation 
> line above to clobber the original library binary, in usr merge (/lib64 
> and /usr/lib64 are the same dir) cases, or at least when /usr -> . (aka 
> "reverse" usr merge).
> 
> 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 
> perhaps it's acting differently now due to the recent migration away from 
> eblits?  What I know for sure is that the upgrade broke my system until I 
> 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 system.

I think this discussion belongs to https://bugs.gentoo.org/627378

-- 

  Sergei

[-- Attachment #2: Цифровая подпись OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[gentoo-dev] Re: [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

[Duncan]

Sergei Trofimovich posted on Fri, 11 Aug 2017 09:14:42 +0100 as excerpted:

> What is your point there? I'm afraid I lost you.

Just saying interesting it's the same lib and apparently the same 
symlinking logic and line involved, and while it doesn't seem to be the 
same bug, it might be worth a bit of extra care while fixing the one to 
keep in mind the other so as not to further complicate fixing it, is all.

(I'll be working on my bug either late today/Friday or Saturday.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman