| View previous topic :: View next topic |
| Author |
Message |
jagdpanther
l33t
Joined: 22 Nov 2003
Posts: 729
|
 Posted: Tue Jun 19, 2018 6:23 pm Post subject: Should I Switch to stable gcc-7.3 ? |
 |
|
gcc-7.3.0 is "stable" on my 64-bit Intel based system and emerged into a new slot:
| Code: | $ gcc-config -l
[1] x86_64-pc-linux-gnu-6.4.0 *
[2] x86_64-pc-linux-gnu-7.3.0 |
Should I follow the Gentoo Wiki guide on upgrading gcc, https://wiki.gentoo.org/wiki/Upgrading_GCC or stick with gcc-6.4.0?
(I am cautious when upgrading gcc, glibc or binutils.) |
|
| Back to top |
|
 |
Nreal
Apprentice
Joined: 06 Jan 2009
Posts: 265
|
| Posted: Tue Jun 19, 2018 6:26 pm Post subject: |
|
|
markus@boxi ~ $ gcc-config -l
[1] x86_64-pc-linux-gnu-7.3.0
[2] x86_64-pc-linux-gnu-8.1.0 *
markus@boxi ~ $ |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30915
Location: here
|
| Posted: Tue Jun 19, 2018 6:28 pm Post subject: |
|
|
7.3.0 is marked stable then switch.
_________________
Questions are guaranteed in life; Answers aren't. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54237
Location: 56N 3W
|
| Posted: Tue Jun 19, 2018 6:29 pm Post subject: |
|
|
jagdpanther,
gcc-6.x will be masked one day. Don't wait too long before you update.
Avoid both extremes.
Don't be last out of the past, nor first into the future :).
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
bandreabis
Advocate
Joined: 18 Feb 2005
Posts: 2490
Location: イタリアのロディで
|
| Posted: Tue Jun 19, 2018 7:39 pm Post subject: |
|
|
after switched? Any mandatory command?
_________________
Il numero di post non fa di me un esperto! Anzi! |
|
| Back to top |
|
|
fedeliallalinea
Administrator
Joined: 08 Mar 2003
Posts: 30915
Location: here
|
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 2963
Location: Edge of marsh USA
|
| Posted: Wed Jun 20, 2018 2:23 am Post subject: |
|
|
| bandreabis wrote: | | after switched? Any mandatory command? |
For several years, I've just switched gcc versions, then emerge -1 libtool. No problems at all.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Wed Jun 20, 2018 2:34 am Post subject: |
|
|
I too, after years with Gentoo, just pause for a brief period and let some of the best questions get answered by the wizards here in the forums. Then switch.
I tend to take the Rebuild Everything approach: https://wiki.gentoo.org/wiki/Upgrading_GCC#Rebuilding_everything
Cheers |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Jun 20, 2018 9:54 am Post subject: |
|
|
I on the other hand hardly recompile anything. Most of my system is still compiled with the 4.9.4 compiler, but I'm running 6.4.0.
But when moving from 6.* to 7.* there is no need to recompile for "c++ abi changes" because they didn't change from 6 to 7.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Wed Jun 20, 2018 10:13 am Post subject: |
|
|
| figueroa wrote: | | For several years, I've just switched gcc versions, then emerge -1 libtool. No problems at all. |
That's certainly not true for the GCC-4 to GCC-5 migration, but that's why there are news items. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Jun 20, 2018 3:24 pm Post subject: |
|
|
Since it's stable, I'm moving to the new gcc.
Usually I just do the minimum suggested - libtool and I see now that llvm and clang may be suggested as minimum, too.
However in this case, I've read that there are significant security issues with respect to Spectre/Meltdown. Up until now I've just had "minimal retpoline" compiled into the kernel. My impression is that gcc-7 will give me "full retpoline" and I'm not sure if there's more. I'm rebuilding one system now with the new gcc, and installing gcc on two more.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Wed Jun 20, 2018 7:04 pm Post subject: |
|
|
At least "emerge -e @system" to ensure that the toolchain is consistent.
No problems with ebuilds on this system. I have another that needed some environments on, I think, two packages.
Keep both versions but make 7 the default.
UPDATE:
abiword needed CXXFLAGS+=" -std=gnu++98"
so did media-sound/ardour
If you use these and need help setting the environment for gcc 7 in /etc/portage/env just ask. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Wed Jun 20, 2018 7:31 pm Post subject: |
|
|
| Tony0945 wrote: | UPDATE:
abiword needed CXXFLAGS+=" -std=gnu++98"
so did media-sound/ardour |
Ultimately, no. This would indicate some broken lib(s) on your system from a botched GCC-5 migration. Please don't spread confusion among stable users. |
|
| Back to top |
|
|
russK
l33t
Joined: 27 Jun 2006
Posts: 665
|
| Posted: Thu Jun 21, 2018 12:20 am Post subject: |
|
|
| "Rebuild Everything" on my box rebuilt 1173 packages, no issues. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Jun 21, 2018 12:25 am Post subject: |
|
|
| asturm wrote: | | Tony0945 wrote: | UPDATE:
abiword needed CXXFLAGS+=" -std=gnu++98"
so did media-sound/ardour |
Ultimately, no. This would indicate some broken lib(s) on your system from a botched GCC-5 migration. Please don't spread confusion among stable users. |
Well, pardon me! I was just reassuring him that almost all packages (1038 out of 1040) should compile.
But I will bow to your godlike intellect and log off. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Thu Jun 21, 2018 4:42 am Post subject: |
|
|
| Tony0945 wrote: | | But I will bow to your godlike intellect and log off. |
Was it wrong to hold you to a higher standard? Past remarks of yours have made me believe you even were too good to become a dev. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Thu Jun 21, 2018 10:32 am Post subject: |
|
|
Two systems through "emerge -e @system" with no problems, two still running, one system yet to start.
Two systems running "emerge -e @world". Had an issue with amdgpu_pro_opencl on one system, did "emerge --skipfirst --resume" to get past it, and I'll check it out in detail later.
Yeah, I'm rebuilding everything, but it's only compute time and a little electricity. Getting gcc-7 with better spectre/meltdown fixes will feel better.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
ali3nx
l33t
Joined: 21 Sep 2003
Posts: 722
Location: Winnipeg, Canada
|
| Posted: Thu Jun 21, 2018 3:00 pm Post subject: |
|
|
One major reason to recompile everything including your kernel is the spectre and meltdown cpu flaws or relevant AMD cpu bug comparisons.
gcc 7.3 has the compiler features to enable full meltdown and spectre cpu bug mitigations at compile time and iirc only recompiling kernel and software packages will enable the compile time mitigations.
There's two new cpu bugs discovered recently that in time may be fixed on older cpu hardware but for now compiling software with a compiler that supports Full generic retpoline compilation is sufficient to mitigate meltdown, spectre v1 and v2
The tool used to check if your system is vulnerable can be located here
https://github.com/speed47/spectre-meltdown-checker
| Code: | fenrir ~/spectre-meltdown-checker # ./spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.37+
Checking for vulnerabilities on current system
Kernel is Linux 4.16.14-gentoo #1 SMP Wed Jun 13 16:07:36 CDT 2018 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU microcode is known to cause stability problems: NO (model 0x3e family 0x6 stepping 0x4 ucode 0x428 cpuid 0x306e4)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer sanitization)
* Kernel has array_index_mask_nospec (x86): YES (1 occurrence(s) found of 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: NO
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline is mitigating the vulnerability)
IBPB is considered as a good addition to retpoline for Variant 2 mitigation, but your CPU microcode doesn't support it
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports PCID, performance impact of PTI will be reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)
> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).
A false sense of security is worse than no security at all, see --disclaimer |
_________________
Compiling Gentoo since version 1.4
Thousands of Gentoo Installs Completed
Emerged on every continent but Antarctica
Compile long and Prosper! |
|
| Back to top |
|
|
|
Portage & Programming
