With sys-libs/glibc-2.27 I cannot compile anything since most packages try to include gnu/stubs-32.h which doesn't exist anymore. And downgrading glibc has been inhibited. One has to replay a recent backup - very annoying. (Yes, glibc-2.27 is masked but it's like a bomb here)
https://github.com/gentoo/gentoo/commit/6b78adca56668c98bb5b0fe55d999a9d8d159413 sys-libs/glibc: Version bump. Untested, unkeyworded. Since it's masked maybe you were the first to test it.
Can you please attach a failure log to see what's happening?
Created attachment 517606 [details] build log for bzip2 Having install glibc-2.27 @preserved-rebuild contains bzip2. e.g. Furthermore trying to recompile sys-devel/gcc:7.3.0 fails because of the same problem : there is no file /usr/include/gnu/stubs-32.h
Created attachment 517608 [details] build log for gcc-7.3.0 xz-compressed
Please also provide your $(emerge --info) output.
Can you compile again if you remove the gnu/stubs-32.h include from /usr/include/gnu/stubs.h?
I managed to hose one of my machine doing this too I've built a copy of glibc-2.26-r5 with -O2 -pipe (so should work on any amd64 multilib machine) If you extract the archive at https://drive.google.com/open?id=11uljgIIeC5tpYnzZDp-xhG4_fSdFat8G into /usr/portage/packages/ You can then: emerge -GO1 glibc Once it's restored you can then re-emerge glibc to use your flags again: emerge -O1 glibc This only works if no packages have been built against glibc-2.27 which should be the case
Can you attach emerge --info output?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a2f034415d6e9c5c0135136b4e28698f3a15767 commit 3a2f034415d6e9c5c0135136b4e28698f3a15767 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-02-03 01:17:00 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-02-03 01:18:42 +0000 sys-libs/glibc: unbreak installation of non-default ABIs, bug #646424 multilib.eclass has a EMULTILIB_PKG="true" knob to declare package as multilib-compatible. This knob was lost in glibc-2.27 in commit e77866cf2155f9b9a74c015589f3ac95a8edc2be ("sys-libs/glibc: Various cleanups. Work in progress.") Closes: https://bugs.gentoo.org/646424 Package-Manager: Portage-2.3.20, Repoman-2.3.6 sys-libs/glibc/{glibc-2.27.ebuild => glibc-2.27-r1.ebuild} | 2 ++ sys-libs/glibc/glibc-9999.ebuild | 2 ++ 2 files changed, 4 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2b297eb4b3b9114b1663b5affd9e3a9f0c22fedd commit 2b297eb4b3b9114b1663b5affd9e3a9f0c22fedd Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-02-03 01:38:38 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-02-03 01:38:38 +0000 sys-libs/glibc: restore ability to switch single->multiple ABIs To recover broken system automatically from bug #646424 we need to skip IA32 ABI checks as those require multiabi glibc checks at glibc build time. There is no need to impose it as a requirement. Fail test only if it compiled successfully and failed at runtime. Bug: https://bugs.gentoo.org/326693 Bug: https://bugs.gentoo.org/646424 Package-Manager: Portage-2.3.20, Repoman-2.3.6 sys-libs/glibc/glibc-2.27-r1.ebuild | 14 ++++++++++---- sys-libs/glibc/glibc-9999.ebuild | 14 ++++++++++---- 2 files changed, 20 insertions(+), 8 deletions(-)}
Not cool folks, had to pull stage3 and manually copy /lib32 stuff to my root to get stuff compiling again. Think this is the third time I glibc broke on my box in recent years, at least this time it haven't bricked machine entirely. Perhaps this should get masked via profile once again? I suppose that unkeyworded package comes with no assurances, but broken glibc literally breaks the entire box and I don't think users are warned strongly enough here.
(In reply to Tomas Pruzina from comment #11) > Not cool folks, had to pull stage3 and manually copy /lib32 stuff to my root > to get stuff compiling again. The only thing you need to do is to sync to latest ::gentoo and emerge -1 =glibc-1.27-r1. > Perhaps this should get masked via profile once again? If it does not help please file new bug (or search for similar existing ones).
(In reply to Sergei Trofimovich from comment #12) > The only thing you need to do is to sync to latest ::gentoo and emerge -1 > =glibc-1.27-r1. Sorry, wasn't descriptive enough, just ranting that I had to workaround it while rc1 wasn't out yet because I needed my 32bit stuff to work. At the time I had no idea this would get fixed/worked around in rc1 ebuild.
