| Summary: | gcc-4.8.0 to gcc-4.8.1 update removes /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/ and breaks everything | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Tomi Salminen <tlsalmin> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | CC: | erikdenstore+gbugs, galtgendo, god, main.haarp |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
/var/log/portage/elog/summary.log build.log.gz |
||
Created attachment 350098 [details]
/var/log/portage/elog/summary.log
https://bugs.gentoo.org/show_bug.cgi?id=471862#add_comment This bug seems to have the same issue, but with an older gcc. What does `gcc-config -l` show? Also, as Tom Wijsman says in the bug report you linked - can you give us the build.log? You might be able to find it in PORT_LOGDIR (usually /var/log/portage/). Ah yes after the reboot, gcc-config -l showed that none were selected. I was too hasty to get the system up to actually try gcc-config setting after the update for a system fix. Also the exact error message slipped past me for the same reason. Do ln -s /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/libgcc_s.so.1 /usr/lib64/libgcc_s.so.1 as a dirty helping hack. In addition I had to switch to gcc-4.8.1 manualy after postrm phase failed. (In reply to Tomi Salminen from comment #4) > Ah yes after the reboot, gcc-config -l showed that none were selected. I was > too hasty to get the system up to actually try gcc-config setting after the > update for a system fix. So after properly selecting the new gcc with `gcc-config` everything works? Anyways, lets see what toolchain@ thinks about this. (In reply to Denis M. (Phr33d0m) from comment #6) > So after properly selecting the new gcc with `gcc-config` everything works? I had the same problem. Yes, rerunning gcc-config (followed by env-update) helps. The problem lies here: # grep -r 4.8.0 /etc/* Binary file /etc/ld.so.cache matches /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf:/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/32 /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf:/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0 Which disappears after running gcc-config. Also happened with a previous gcc for me. I can confirm the breakage, and that manually switching gcc version with gcc-config fixed it. (I had an older version selected, and it got fixed by switching to gcc-4.8.1) As a (possibly useless) side note, I'm fairly sure the exact same thing happened at least once while upgrading between gcc-4.7 minors. Created attachment 350122 [details] build.log.gz (In reply to Denis M. (Phr33d0m) from comment #3) > What does `gcc-config -l` show? > > Also, as Tom Wijsman says in the bug report you linked - can you give us the > build.log? You might be able to find it in PORT_LOGDIR (usually > /var/log/portage/). gcc-config -l showed that my system compiler (4.7.3) remained selected. I attached my build.log. *** This bug has been marked as a duplicate of bug 433161 *** |
Created attachment 350096 [details] emerge --info I updated gcc to 4.8.1 from 4.8.0 being the active one. The emerge failed at a 'postinst ebuild exited unexpectedly' and subsequently every tool breaking on 'error while loading shared libraries libgcc_s.so.1'. I 'resolved' the issue by linking /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/ to /usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.1/ and everything works again. I have my /var/tmp mounted as tmpfs so I regretfully cannot provide a build.log. I'll add a snippet from /var/log/portage/elog/summary.log as attachment