Trying to install Gentoo with an i586 CHOST, I started with an i486 stage3 and tried to change it to i586 after unpacking. This was on an i586 machine, an AMD K6-III. Out of experience, I found that getting to the first emerge @world is best, before changing the CHOST. I used the default profile, so there were only about 12-13 packages to compile during the first emerge @world. Among them, binutils 2.35.1-r1, which failed to compile. I moved the hard drive to another computer, started from an i686 stage3 (stage3-i686-20210201T214503Z.tar.xz) and this time, I could compile binutils 2.35.1-r1 The first step in the guide to change the CHOST is to recompile binutils. After declaring the i586 CHOST, I could only compile version 2.34-r2. Put the drive back in the i586 machine, proceeded to compile gcc and glibc, then moved to do "emerge --emptytree @system" excluding binutils, but it tried to compile binutils-libs 2.35.1-r1 and failed with, apparently, the exact same error. The CHOST was already changed to i586. I tried to manually emerge binutils-libs 2.34-r2, succeeded, and then did "emerge --emptytree @system" but excluding binutils and binutils-libs. It worked. Then I did "emerge --emptytree @world" which is still going on right now. P.S. As a bonus weird part, equery the i586 system now reports sys-devel/binutils both 2.34-r2 and 2.35.1-r1 as installed! sys-libs/binutils-libs only reports 2.34-r2. Reproducible: Always Steps to Reproduce: For the i486 CHOST: 1. start a new installation of Gentoo with an i486 stage3 2. try to compile binutils 2.35 For the i586 CHOST: 1. start a new installation of Gentoo with an i686 stage3 2. set the default profile 3. get to the first emerge @world in the installation tutorial and do it 4. change CHOST to i586 5. try to compile binutils 2.35
Created attachment 686325 [details] build.log for sys-devel/binutils
Created attachment 686328 [details] build.log for sys-libs/binutils-libs
Created attachment 686331 [details] emerge --info sys-devel/binutils
Created attachment 686334 [details] emerge --info binutils-libs
(In reply to subzero_ro from comment #0) > Trying to install Gentoo with an i586 CHOST, I started with an i486 stage3 > and tried to change it to i586 after unpacking. This was on an i586 machine, > an AMD K6-III. > Out of experience, I found that getting to the first emerge @world is best, > before changing the CHOST. > > I used the default profile, so there were only about 12-13 packages to > compile during the first emerge @world. Among them, binutils 2.35.1-r1, > which failed to compile. > > I moved the hard drive to another computer, started from an i686 stage3 > (stage3-i686-20210201T214503Z.tar.xz) and this time, I could compile > binutils 2.35.1-r1 > > The first step in the guide to change the CHOST is to recompile binutils. Do you follow https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable? > After declaring the i586 CHOST, I could only compile version 2.34-r2. Put > the drive back in the i586 machine, proceeded to compile gcc and glibc, then > moved to do "emerge --emptytree @system" excluding binutils, but it tried to > compile binutils-libs 2.35.1-r1 and failed with, apparently, the exact same > error. The CHOST was already changed to i586. > I tried to manually emerge binutils-libs 2.34-r2, succeeded, and then did > "emerge --emptytree @system" but excluding binutils and binutils-libs. It > worked. Then I did "emerge --emptytree @world" which is still going on right > now. > > P.S. As a bonus weird part, equery the i586 system now reports > sys-devel/binutils both 2.34-r2 and 2.35.1-r1 as installed! > sys-libs/binutils-libs only reports 2.34-r2. > > Reproducible: Always > > Steps to Reproduce: > For the i486 CHOST: > > 1. start a new installation of Gentoo with an i486 stage3 > 2. try to compile binutils 2.35 > > For the i586 CHOST: > > 1. start a new installation of Gentoo with an i686 stage3 > 2. set the default profile > 3. get to the first emerge @world in the installation tutorial and do it > 4. change CHOST to i586 > 5. try to compile binutils 2.35 I don't think it is going to work as is.
(In reply to Sergei Trofimovich from comment #5) > > Do you follow https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable? > Yes, of course I do, that's the procedure I meant. I already have CHOST and CHOST_x86 in make.conf, to make sure. > > I don't think it is going to work as is. > As far as I know, on i686 it does work. Unpack the latest stage3, chroot, emerge binutils. Hence the bug.
(In reply to subzero_ro from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > Do you follow https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable? > > Yes, of course I do, that's the procedure I meant. I already have CHOST and > CHOST_x86 in make.conf, to make sure. The page is outdated and was never officially supported. > > I don't think it is going to work as is. > > As far as I know, on i686 it does work. Unpack the latest stage3, chroot, > emerge binutils. > Hence the bug. CHOST change breaks many assumptions of live system (CBUILD /= CHOST).
(In reply to Sergei Trofimovich from comment #7) > (In reply to subzero_ro from comment #6) > > (In reply to Sergei Trofimovich from comment #5) > > > Do you follow https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable? > > > > Yes, of course I do, that's the procedure I meant. I already have CHOST and > > CHOST_x86 in make.conf, to make sure. > > The page is outdated and was never officially supported. > CHOST change breaks many assumptions of live system (CBUILD /= CHOST). Even so, you'd only be talking about half the problem - i586. It still doesn't work if you use an i486 stage3. Please don't try to blame all of this bug on the CHOST change. Since it won't work with the exact same error on either i486 or i586, I'm guessing following that outdated and unsupported tutorial on the CHOST change will compile just fine after the issue is repaired for i486. Want the build.log / emerge --info for i486, directly from Gentoo's stage3?
(In reply to subzero_ro from comment #8) > (In reply to Sergei Trofimovich from comment #7) > > (In reply to subzero_ro from comment #6) > > > (In reply to Sergei Trofimovich from comment #5) > > > > Do you follow https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable? > > > > > > Yes, of course I do, that's the procedure I meant. I already have CHOST and > > > CHOST_x86 in make.conf, to make sure. > > > > The page is outdated and was never officially supported. > > > CHOST change breaks many assumptions of live system (CBUILD /= CHOST). > > Even so, you'd only be talking about half the problem - i586. It still > doesn't work if you use an i486 stage3. > > Please don't try to blame all of this bug on the CHOST change. Since it > won't work with the exact same error on either i486 or i586, I'm guessing > following that outdated and unsupported tutorial on the CHOST change will > compile just fine after the issue is repaired for i486. > > Want the build.log / emerge --info for i486, directly from Gentoo's stage3? Oh, it was not clear CHOST change is not necessary. My apologies. Let's see if I can reproduce it on http://distfiles.gentoo.org/releases/x86/autobuilds/current-stage3-i486/stage3-i486-20210208T214503Z.tar.xz
> checking for working mmap... configure: error: Intel CET must be enabled on Intel CET enabled host This is probably another case of bug #760926.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b9ebe18fbe66e5c1584744a1658602785c6bd784 commit b9ebe18fbe66e5c1584744a1658602785c6bd784 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-02-11 20:20:06 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-02-11 20:21:56 +0000 profiles/base/package.use.mask: mask binutils-*[cet] Reported-by: subzero_ro@yahoo.com Closes: https://bugs.gentoo.org/770061 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> profiles/base/package.use.mask | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d2f7c9935b63554f65183746c7460f211a803c79 commit d2f7c9935b63554f65183746c7460f211a803c79 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-02-11 20:17:51 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-02-11 20:21:56 +0000 sys-devel/binutils-hppa64: make CET optional (and disabled by default) Reported-by: subzero_ro@yahoo.com Bug: https://bugs.gentoo.org/770061 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/binutils-hppa64/binutils-hppa64-2.35.1-r1.ebuild | 7 ++++++- sys-devel/binutils-hppa64/binutils-hppa64-2.35.2.ebuild | 7 ++++++- sys-devel/binutils-hppa64/binutils-hppa64-2.36.1.ebuild | 7 ++++++- sys-devel/binutils-hppa64/metadata.xml | 1 + 4 files changed, 19 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cd833222cbaef1cd344f3b06c528b858c06dc04a commit cd833222cbaef1cd344f3b06c528b858c06dc04a Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-02-11 20:17:33 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-02-11 20:21:56 +0000 sys-devel/binutils: make CET optional (and disabled by default) Reported-by: subzero_ro@yahoo.com Bug: https://bugs.gentoo.org/770061 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/binutils/binutils-2.35.1-r1.ebuild | 7 ++++++- sys-devel/binutils/binutils-2.35.2.ebuild | 7 ++++++- sys-devel/binutils/binutils-2.36.1.ebuild | 7 ++++++- sys-devel/binutils/binutils-9999.ebuild | 7 ++++++- sys-devel/binutils/metadata.xml | 1 + 5 files changed, 25 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=631038dec7129bd3f5d859170b2c11bd6d1b8264 commit 631038dec7129bd3f5d859170b2c11bd6d1b8264 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2021-02-11 20:16:15 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2021-02-11 20:21:55 +0000 sys-libs/binutils-libs: make CET optional (and disabled by default) Reported-by: subzero_ro@yahoo.com Bug: https://bugs.gentoo.org/770061 Package-Manager: Portage-3.0.14, Repoman-3.0.2 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> .../binutils-libs/binutils-libs-2.35.1-r1.ebuild | 7 ++++++- sys-libs/binutils-libs/binutils-libs-2.35.2.ebuild | 7 ++++++- sys-libs/binutils-libs/binutils-libs-2.36.1.ebuild | 7 ++++++- sys-libs/binutils-libs/metadata.xml | 23 +++++++++++----------- 4 files changed, 30 insertions(+), 14 deletions(-)
Please give it a try. The change should add USE=cet (disabled by default) that should disable sse2 instructions. I'll file an upstream bug as it seems to proliferate to a bunch of binutils-based packages.
Can you also check if patch in https://sourceware.org/PR27397 fixes binutils from git for you? You might need to run autoconf once you apply the patch.
(In reply to Sergei Trofimovich from comment #13) > Can you also check if patch in https://sourceware.org/PR27397 fixes binutils > from git for you? You might need to run autoconf once you apply the patch. I could only do this, as it seems I'm unable to work with overlays in Gentoo. I managed to save the upstream patch as a simple text file, then I put it in /etc/portage/patches/sys-devel/binutils/ as per another Gentoo user's recommendations. It failed to compile just the same. Attaching the new build log and the patch file I used (just to check I saved it properly)
Created attachment 686379 [details, diff] patch file
Created attachment 686382 [details] build log post-patching
(In reply to subzero_ro from comment #14) > (In reply to Sergei Trofimovich from comment #13) > > Can you also check if patch in https://sourceware.org/PR27397 fixes binutils > > from git for you? You might need to run autoconf once you apply the patch. > > I could only do this, as it seems I'm unable to work with overlays in Gentoo. > > I managed to save the upstream patch as a simple text file, then I put it in > /etc/portage/patches/sys-devel/binutils/ as per another Gentoo user's > recommendations. > > It failed to compile just the same. Attaching the new build log and the > patch file I used (just to check I saved it properly) That should do it. Thanks for the test! It's unfortunate it still does not work. Can you also attach libiberty/config.log for completeness?
Created attachment 686394 [details] libiberty config.log file
(In reply to Sergei Trofimovich from comment #17) > > Can you also attach libiberty/config.log for completeness? Attached. Now, if you want, I can do this again, separately, for the i486 environment. It would be even easier not having to recompile so much.
Created attachment 686436 [details, diff] binutils-gdb-fix-cet.patch Try binutils-gdb-fix-cet.patch. I think the real bug is just a logic inversion. Testing against i486 should be totally fine as well.
It's compiling!! I'm going to try it on binutils-libs after it finishes, unless you tell me not to. i486 tests to follow later today. Thank you very much, please keep asking for whatever other tests/info you need. Like maybe the build.log of this successful emerge.
Patch should apply to binutils-libs and gdb as is as well. I'll ask upstream if it's a resonable fix or the test is intended to detect CET hosts.
Hi, sorry for butting in, should CET be a new CPU_FLAGS_X86? Seems like this is a new feature for Tigerlake and newer
(In reply to Mike Lothian from comment #23) > Hi, sorry for butting in, should CET be a new CPU_FLAGS_X86? Seems like this > is a new feature for Tigerlake and newer Good question. Maybe. Normally CPU features (like avx2) just work (assuming kernel unconditionally supports new CPUs with full), are enabled on a final binary/library and don't require extra runtime. CET is a bit odd: 1. On ISA level it uses sse2 NOP instruction that got new behaviour on CET-aware CPUs (which is strictly speaking a backward incompatible ISA breakage). CPU_FLAGS_X86=sse2 would be a very odd way to enable it. CPU_FLAGS_X86=cet would require REQUIRED_USE="cet? ( sse2 )" 2. At linker level it uses different PLT stubs to accomodate shadow return stack (different flag). 3. I'm not sure how good mixing CET and non-CET code works today. Probably ok? It looks more like -fstack-protector= being a mechanism to add extra (CPU-specific) checks with a bit of added runtime overhead. We still should be able to rename the USE-flag later but I'm not sure it's a good fit for CPU_FLAGS_X86.
(In reply to subzero_ro from comment #21) > It's compiling!! > > I'm going to try it on binutils-libs after it finishes, unless you tell me > not to. > > i486 tests to follow later today. > > Thank you very much, please keep asking for whatever other tests/info you > need. Like maybe the build.log of this successful emerge. In https://sourceware.org/PR27397#c5 H.J Lu proposed another patch: https://sourceware.org/bugzilla/attachment.cgi?id=13220 Can you try that one instead? It will have a better chance to hit upstream.
(In reply to Sergei Trofimovich from comment #25) > (In reply to subzero_ro from comment #21) > > It's compiling!! > > > > I'm going to try it on binutils-libs after it finishes, unless you tell me > > not to. > > > > i486 tests to follow later today. > > > > Thank you very much, please keep asking for whatever other tests/info you > > need. Like maybe the build.log of this successful emerge. > > In https://sourceware.org/PR27397#c5 H.J Lu proposed another patch: > https://sourceware.org/bugzilla/attachment.cgi?id=13220 > > Can you try that one instead? It will have a better chance to hit upstream. Looks fine so far. It's compiling. Also, on a new i486 install, binutils 2.35 was already included. I forced recompilation with emerge --oneshot and it compiled just fine without any patch. The make.conf file was more or less the default one supplied with the stage3 archive, so march=i486 and no CPU_FLAGS_X86 at all. I added CHOST_x86 by copying the i486 CHOST and added -fomit-frame-pointer next to -O2 and -pipe.
Woohoo! I hope next autobuilds of degault gentoo's stage3 will avoid cet instruction in binutils entirely and we will have something that just runs on i486.
Upstream H.J. Lu asks to try one more patch: https://sourceware.org/bugzilla/show_bug.cgi?id=27397#c10 As ebuilds already have a workaround I suggest checking it by testing in real binutils-gdb git repository: git://sourceware.org/git/binutils-gdb.git Without the patch $ ./configure && make should fail the same you saw before. With the patch $ ./configure && make should succeed and disable CET.
(In reply to Sergei Trofimovich from comment #28) > Upstream H.J. Lu asks to try one more patch: > https://sourceware.org/bugzilla/show_bug.cgi?id=27397#c10 > > As ebuilds already have a workaround I suggest checking it by testing in > real binutils-gdb git repository: > > git://sourceware.org/git/binutils-gdb.git > > Without the patch > $ ./configure && make > should fail the same you saw before. > > With the patch > $ ./configure && make > should succeed and disable CET. I saw that and already tried re-building my i586 install packages with it. I haven't done emerge --sync and so, I have the old, non-workaround ebuilds. Both binutils and binutils-libs compiled successfully. (binutils-libs had never been updated to 2.35, I always had 2.34 installed. binutils proper was recompiled with emerge --oneshot.) Maybe I should try the patch with the git version on a fresh i486 stage3? In chroot, where yes, the packages already have a built-in workaround.
(In reply to subzero_ro from comment #29) > (In reply to Sergei Trofimovich from comment #28) > > Upstream H.J. Lu asks to try one more patch: > > https://sourceware.org/bugzilla/show_bug.cgi?id=27397#c10 > > > > As ebuilds already have a workaround I suggest checking it by testing in > > real binutils-gdb git repository: > > > > git://sourceware.org/git/binutils-gdb.git > > > > Without the patch > > $ ./configure && make > > should fail the same you saw before. > > > > With the patch > > $ ./configure && make > > should succeed and disable CET. > > I saw that and already tried re-building my i586 install packages with it. I > haven't done emerge --sync and so, I have the old, non-workaround ebuilds. > Both binutils and binutils-libs compiled successfully. (binutils-libs had > never been updated to 2.35, I always had 2.34 installed. binutils proper was > recompiled with emerge --oneshot.) > > Maybe I should try the patch with the git version on a fresh i486 stage3? In > chroot, where yes, the packages already have a built-in workaround. Having the old version is handy. I reported it as working for you as well: https://sourceware.org/PR27397#c11
