Created attachment 653224 [details] end of build.log Fails about 20% into the compilation process. I tried upgrading gcc, binutils, glib, glib-utils, glibc, gobject-introspection, and it still failed there. Any idea what might be causing this? (That "@GLIBCXX_3.4.26" error message from ld looks weird. It's the only time it appears in the 12MB build.log. I have nothing with that version on my system.)
don't omit emerge --info
Comment on attachment 653224 [details] end of build.log Please attach the complete build log to this bug report. Please use a compression utility (but not an archiver) to reduce its file size before uploading.
I think the issue might be related to this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782 But I was compiling stuff with gcc-8.3 for over a year without this issue. I recently upgraded to gcc-10.2 Other packages that depend on webkit-gtk are also failing with this error message. For example, www-client/luakit, and www-client/surf: x86_64-pc-linux-gnu-gcc -o surf surf.o -lX11 -lgthread-2.0 -pthread -lwebkit2gtk-4.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -ljavascriptcoregtk-4.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/libwebkit2gtk-4.0.so: undefined reference to `std::_Sp_make_shared_tag::_S_eq(std::type_info const&)@GLIBCXX_3.4.26' When I try to "eselect gcc set" back to 8.3, I get a similar error message, but with the 8.3.0/ directory: x86_64-pc-linux-gnu-gcc -o surf surf.o -lX11 -lgthread-2.0 -pthread -lwebkit2gtk-4.0 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lsoup-2.4 -lgio-2.0 -ljavascriptcoregtk-4.0 -lgobject-2.0 -lglib-2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/libwebkit2gtk-4.0.so: undefined reference to `std::_Sp_make_shared_tag::_S_eq(std::type_info const&)@GLIBCXX_3.4.26' Any idea how to fix this? Do I have to recompile everything with the new gcc-10.2? :S Sigh.
Oh btw I was able to compile net-libs/webkit-gtk-2.28.4 after disabling "introspection" and recompiling libstdc++-v3 (I'm not sure which of these two did the trick).
... and after upgrading net-libs/webkit-gtk, I can no longer run any of my browsers that depend on it. $ surf surf: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib64/libwebkit2gtk-4.0.so.37) surf: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /usr/lib64/libjavascriptcoregtk-4.0.so.18) What a nightmare :s
(In reply to Dennis Nezic from comment #5) > ... and after upgrading net-libs/webkit-gtk, I can no longer run any of my > browsers that depend on it. > > $ surf > surf: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so.6: version > `GLIBCXX_3.4.26' not found (required by /usr/lib64/libwebkit2gtk-4.0.so.37) > surf: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/libstdc++.so.6: version > `GLIBCXX_3.4.26' not found (required by > /usr/lib64/libjavascriptcoregtk-4.0.so.18) > > What a nightmare :s GLIBCXX_3.4.26-versioned symbols were added after gcc-9.1.0. That means you have built and linked /usr/lib64/libjavascriptcoregtk-4.0.so.18 with gcc-9's libstdc++ or above. If you want it to be compatible with older gccs you need to rebuild libjavascriptcoregtk-4.0.so.18 library (and perhaps it's dependencies) with older (current) gcc. Note: downgrading libraries in general is more painful process as you are removing symbols that were introduced in newer versions.
I "fixed" the issue via some ugly hacking: I made /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0 a symlink to the new 10.2.0 directory ... so that the old apps now use the newly compiled libstdc++.so. Now I can run the old browsers, and compile them again. So I guess this is some nasty issue with upgrading sys-devel/gcc and/or sys-libs/libstdc++
(In reply to Dennis Nezic from comment #7) > I "fixed" the issue via some ugly hacking: I made > /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0 a symlink to the new 10.2.0 directory > ... so that the old apps now use the newly compiled libstdc++.so. Now I can > run the old browsers, and compile them again. That's a good way to break your system. If you still have gcc-10 installed it's library is supposed to be used first. Check contents of /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf and make sure you have gcc-10's path first and valid.
Thanks for the info Sergei! 05gcc-x86_64-pc-linux-gnu.conf indeed had 8.3.0 listed first. I will reverse that and see if it helps. Recompiling gcc (many hours) and webkit-gtk (even more hours than gcc... ie. days) will not be fun :'(. Perhaps we should be warned against upgrading to the latest gcc to avoid this mess?
Seems like nothing to do for gnome@, so switching around the assignee and CC between gnome and toolchain
(In reply to Dennis Nezic from comment #9) > Thanks for the info Sergei! 05gcc-x86_64-pc-linux-gnu.conf indeed had 8.3.0 > listed first. I will reverse that and see if it helps. I suggest not edit toolchain files manually. It's hard to see what was broken due to software bugs and what was broken by manual edits. The order is supposed to be correct. We fixed it in gcc-config-2.2 and above as: https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=bc80e12ab133a00ece4059df40d672889fcf6bf0 You were asked to provide emerge --info. That would contain gcc-config version. Can you attach the emerge --info result? > Recompiling gcc (many hours) and webkit-gtk (even more hours than gcc... ie. > days) will not be fun :'(. > > Perhaps we should be warned against upgrading to the latest gcc to avoid > this mess? We need to find out first what is causing the problem. Does your gcc-config still generate invalid ordering if you switch gcc versions around? 05gcc-x86_64-pc-linux-gnu.conf ordering is supposed not to depend on selected gcc version.
I was using an old version of gcc-config (1.9.1). The newer ones did indeed properly order 05gcc.. stuff. shouldn't >=gcc-config-2.2 have been made a dependency for gcc-10 ? :s
(In reply to Dennis Nezic from comment #12) > I was using an old version of gcc-config (1.9.1). The newer ones did indeed > properly order 05gcc.. stuff. shouldn't >=gcc-config-2.2 have been made a > dependency for gcc-10 ? :s In a perfect world yes, lower bound should be there. As well as many other lower bound dependencies from distant past. It makes sense to hale a lower bound when there is a reasonable change to have an outdated version installed. But generally Gentoo does not add dependencies against outdated package versions and assumes system is reasonably (at least ~6 months old fresh) up to date. If you keep packages long deleted from the tree and use it against fresh ebuilds in tree then many assumptions start to break. gcc-config-1.9.1 was removed from ::gentoo more than a half a year before gcc-10 was added: commit 98b755b5beb5eb359a7cd9b59733d9642f12a829 Author: Sergei Trofimovich <slyfox@gentoo.org> Date: Fri Aug 16 00:00:11 2019 +0100 sys-devel/gcc-config: drop old commit 32258c6414a31898ff5592893678a3910d2c5c75 Author: Sergei Trofimovich <slyfox@gentoo.org> Date: Thu May 7 21:55:09 2020 +0100 sys-devel/gcc: bump up to 10.1.0 I suggest upgrading your system to get it into a consistent state. https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Portage#Updating_the_system has details on how to do it.
(In reply to Sergei Trofimovich from comment #13) > But generally Gentoo does not add dependencies against outdated package > versions and assumes system is reasonably (at least ~6 months old fresh) up > to date. If you keep packages long deleted from the tree and use it against > fresh ebuilds in tree then many assumptions start to break. As gnome@ was the initial project involved here, I want to point out that gnome@ packages carry minimum versions as known to be needed, even if older than the minimum needed has been long gone. And that I'm not aware of any such generic standard to not properly express minimum dependencies when they are known - and even less so cases where a minimum dep is expressed, but it's found to be wrong (toolchain.eclass has an explicit >=gcc-config-1.7 PDEPEND).
(In reply to Mart Raudsepp from comment #14) > (In reply to Sergei Trofimovich from comment #13) > > But generally Gentoo does not add dependencies against outdated package > > versions and assumes system is reasonably (at least ~6 months old fresh) up > > to date. If you keep packages long deleted from the tree and use it against > > fresh ebuilds in tree then many assumptions start to break. > > As gnome@ was the initial project involved here, I want to point out that > gnome@ packages carry minimum versions as known to be needed, even if older > than the minimum needed has been long gone. And that I'm not aware of any > such generic standard to not properly express minimum dependencies when they > are known and even less so cases where a minimum dep is expressed, but > it's found to be wrong (toolchain.eclass has an explicit >=gcc-config-1.7 > PDEPEND). Good point. We can raise minimum version there.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7b93048f96a905296df6dacbdae52773855f72b9 commit 7b93048f96a905296df6dacbdae52773855f72b9 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-08-07 21:35:19 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-08-07 21:35:19 +0000 toolchain.eclass: raise minimum gcc-config up to 2.3 In #736040 gcc-config-1.9 was not able to handle gcc-10 paths. Let's raise lower bound to minimum stable version currently in ::gentoo. Reported-by: Dennis Nezic Bug: https://bugs.gentoo.org/736040 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
