Created attachment 378974 [details] build.log for net-libs/webkit-gtk-2.4.3 A recent update of my ~amd64 system brought in new versions of webkit-gtk in both slots, both failing in the same way. Compile fails with ./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' Appears somebody reported this upstream a couple of months back but it looks like it died on the vine. Note reporter there is also a gentoo user. I have compiled and attempted to run the sample requested there. It compiled but failed to run with the same undefined reference. Upstream report: https://bugs.webkit.org/show_bug.cgi?id=131274 nosferatu ~ # emerge -pqv '=net-libs/webkit-gtk-2.4.3::gentoo' [ebuild r U ] net-libs/webkit-gtk-2.4.3 [2.2.6] USE="X%* egl gstreamer jit opengl spell webgl (-aqua) -coverage -debug -geoloc -gles2 -introspection -libsecret {-test} -wayland%" [ebuild rR ] net-libs/libproxy-0.4.11-r2 USE="networkmanager perl python webkit -gnome -kde -mono -spidermonkey {-test}" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7 (-python2_6)" The following packages are causing rebuilds: (net-libs/webkit-gtk-2.4.3:3/25::gentoo, ebuild scheduled for merge) causes rebuilds for: (net-libs/libproxy-0.4.11-r2:0/0::gentoo, ebuild scheduled for merge) nosferatu ~ # emerge --info '=net-libs/webkit-gtk-2.4.3::gentoo' Portage 2.2.10 (default/linux/amd64/13.0, gcc-4.7.3, glibc-2.19-r1, 3.15.0-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.15.0-gentoo-x86_64-AMD_FX-tm-6100_Six-Core_Processor-with-gentoo-2.2 KiB Mem: 16414160 total, 3951584 free KiB Swap: 16777212 total, 16765364 free Timestamp of tree: Sun, 15 Jun 2014 15:15:01 +0000 ld GNU ld (GNU Binutils) 2.24 app-shells/bash: 4.2_p47 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6-r1, 3.3.5, 3.4.0 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.7.3-r1, 4.8.2 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.15 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo bitspace-overlay steam-overlay fouxlay soehest Installed sets: @steam ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=native" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.1/conf /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -pipe -march=native" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://www.gtlib.gatech.edu/pub/gentoo http://mirror.mcs.anl.gov/pub/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /var/lib/layman/steam /var/lib/layman/fouxlay /var/lib/layman/soehest" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi adns alsa amd64 avahi bash-completion berkdb bluetooth branding bzip2 cairo calendar cdda cddb cdr cli consolekit cracklib crypt cscope cups curl cxx dbus declarative dga directfb djvu dri dts dv dvb dvd dvdr emacs emboss encode examples exif fam fbcon ffmpeg fftw firefox flac fontconfig fortran gdbm ggi gif gimp git glut gmp gnuplot gnutls gpm gps graphviz gsm gstreamer gtk guile hscolour iconv icu idn imagemagick imlib iodbc ios ipod ipv6 java java6 javascript jbig jingle jpeg jpeg2k kipi kontact ladspa lame lapack latex lcms ldap libcaca libnotify libsamplerate lm_sensors lua lzma lzo mad matroska mmap mms mmx mmxext mng modplug modules mp3 mp4 mpeg mpi mplayer mtp multilib musepack musicbrainz ncurses networkmanager nls nptl nvidia odbc offensive ogg openal openexr opengl openmp pam pango pcre pdf perl phonon plasma plotutils png policykit portaudio postgres postscript ppds pulseaudio python quicktime raw readline rss ruby samba sasl sdl semantic-desktop session slang smp sndfile soap sound source sox speex spell sqlite sqlite3 sse sse2 sse3 sse4_1 ssl ssse3 startup-notification subversion svg syslog taglib tcpd theora threads tidy tiff truetype udev udisks unicode upower usb vcd vdpau vim-syntax vnc vorbis vpx wavpack webkit wifi wmf wxwidgets x264 xcb xcomposite xft xine xml xmp xmpp xosd xpm xscreensaver xv xvid zeroconf zlib zsh-completion" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 emu" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="nlpsolver scripting-beanshell scripting-javascript wiki-publisher" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
This problem goes away if I compile webkit-gtk with gcc-4.8.3. I got a gcc update in the past 24 hours, now webkit-gtk compiles without failure.
It worked for me even on gcc-4.7.3, probably it was a matter of some silent patch tarball bump.
...or (more likely) an eblit change.
Do you have all your system compiled with the same gcc major version? If you have some things compiled with 4.8 and, later, switched back to 4.7, it can cause problems. Also, does enabling/disabling webgl USE change anything?
I have this problem too. I switched to ~amd64 a few days ago and this problem occured. Disabling webgl didn't help. Since the latest gcc version with +amd64 is 4.7.3-r1 and for ~amd64 it's 4.8.3, most probably I have some packages emerged with 4.7 major version. $ emerge --info '=net-libs/webkit-gtk-2.4.3::gentoo' Portage 2.2.8-r1 (default/linux/amd64/13.0/desktop/kde, gcc-4.7.3, glibc-2.19-r1, 3.12.21-gentoo-r1_gg20 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.12.21-gentoo-r1_gg20-x86_64-Intel-R-_Core-TM-_i7-3517U_CPU_@_1.90GHz-with-gentoo-2.2 KiB Mem: 3942428 total, 1116176 free KiB Swap: 4509692 total, 3819088 free Timestamp of tree: Tue, 24 Jun 2014 02:15:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 app-shells/bash: 4.2_p47 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6-r1, 3.3.5, 3.4.0 dev-util/cmake: 2.8.12.2-r1 dev-util/pkgconfig: 0.28-r1 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.10.3, 1.11.6, 1.12.6, 1.13.4, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.7.3-r1, 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.15 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo gentoo-overlay-tox aegypius x-portage ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/themes/oxygen-gtk/gtk-2.0" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--ask-enter-invalid --quiet-build --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://ftp.vectranet.pl/gentoo/ http://gentoo.bloodhost.ru/ http://mirror2.corbina.ru/gentoo-distfiles/ http://mirror.yandex.ru/gentoo-distfiles/ http://tux.rainside.sk/gentoo/ http://ftp.df.lth.se/pub/gentoo/ http://gentoo.kiev.ua/ftp/" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/tox-overlay /var/lib/layman/aegypius /usr/local/portage" SYNC="rsync://rsync.ru.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 bash-completion berkdb bindist bluetooth branding bzip2 cairo cdda cdr cli cmake consolekit cracklib crypt cryptsetup cups cxx dbus declarative dri dts dvd dvdr emacs emboss encode exif fam ffmpeg firefox flac fortran gdbm gif gimp git gpm gtk iconv ipod ipv6 jpeg kde kipi lcms ldap libnotify mad matroska mmx mng modules mp3 mp4 mpeg multilib ncurses networkmanager nls nptl ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds pulseaudio qt3support qt4 readline sdl session spell sse sse1 sse2 ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb valgrind vim vim-syntax vorbis vpx wxwidgets x264 xcb xcomposite xinerama xml xscreensaver xv xvid zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64 pc" INPUT_DEVICES="evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en ru" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="intel" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON $ emerge -pqv '=net-libs/webkit-gtk-2.4.3::gentoo' [ebuild U ] net-libs/webkit-gtk-2.4.3 [2.2.6] USE="X%* egl geoloc gstreamer introspection jit opengl spell (-aqua) -coverage -debug -gles2 -libsecret {-test} -wayland% -webgl*"
Created attachment 379572 [details] build.log with -webgl
OK, this might be a bit more quirky than I thought. Mon Nov 25 12:41:51 2013 >>> sys-devel/gcc-4.7.3-r1 Tue Apr 8 01:37:32 2014 >>> sys-libs/glibc-2.17 Now, do you recall what happened in glibc 2.17 ? I'll give you a hint: check /usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include/g++-v4/i686-pc-linux-gnu/bits/c++config.h (adjust for your CHOST) for the value of _GLIBCXX_USE_CLOCK_* vars - both are still undefined for me. I'll know more, after I'll find time to install gcc 4.7.4 later this week.
Well, with gcc 4.7.4 things still work - mind I didn't rebuild webkit-gtk afterwards, but now instead of the defines, there's an actual symbol in libstdc++, so it doesn't seem as if webkit-gtk should complain anyway.
I have the same bug with gcc 4.8.3 /var/tmp/portage/net-libs/webkit-gtk-2.4.3/work/webkitgtk-2.4.3/.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' collect2: error: ld returned 1 exit status
(In reply to Sergiusz from comment #9) > I have the same bug with gcc 4.8.3 > > /var/tmp/portage/net-libs/webkit-gtk-2.4.3/work/webkitgtk-2.4.3/.libs/ > libwebkitgtk-3.0.so: undefined reference to > `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17' > collect2: error: ld returned 1 exit status [ebuild U ] net-libs/webkit-gtk-2.4.3:3/25 [2.2.6:3/29] USE="X%* egl geoloc gstreamer introspection jit opengl spell webgl (-aqua) -coverage -debug -gles2 -libsecret {-test} -wayland%" 0 kB
Sorry for false alarm, I have forgotten to change gcc from 4.7 to 4.8 :(
I'm seeing this with a gcc 4.7.4 configured, 4.8 installed but never configured as default, and glibc updated recently. However, ldd tells me: # ldd /var/tmp/portage/net-libs/webkit-gtk-2.4.3/work/webkitgtk-2.4.3/.libs/libwebkitgtk-3.0.so | grep -F ++ libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f56b492f000) If I set LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4, then ldd -r won't report any errors any more. So the way I see it, the build is using gcc 4.7, but due to some setting it is using libraries from 4.8.3, apparently both at link time and at run time. Trying to work out the most likely cause for this, I notice the following file: /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf That looks like a likely source to trigger looking in a wrong directory. I moved the 4.7 lines to the top, before the 4.8 ones, and ran ldconfig. Now ldd no longer complains. If this is the correct solution, shouldn't gcc-config be doing this? Looking at the libstdc++.so from 4.7.4 and 4.8.3, I see that the symbol name apparently changed from _ZNSt6chrono12steady_clock3nowEv to _ZNSt6chrono3_V212steady_clock3nowEv, or in demangled form from std::chrono::steady_clock::now() to std::chrono::_V2::steady_clock::now(). The <chrono> header of 4.8.3 has an inline namespace for this. So people who get this to work by 4.8.3 simply avoid the mismatch between compiler and library.
Will CC gcc-config maintainers then as maybe they know about this collisions between gcc 4.7 and 4.8
OK, net-libs/webkit-gtk-2.4.3 emerged all right after I changed the order in /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf followed by running ldconfig. The way I see it at the moment, gcc introduced an incompatible change to the ABI without changing the SONAME of libstdc++. Which in my book is pretty bad practise. Apparently they did so while introducing an inline namespace intended to help maintain ABI compatibility in the future, so I'd have hoped they should know what they are about. I guess that when gcc 4.8 becomes stable, this could cause problems for a number of people, perhaps even for code outside the control of portage. So I'd say we should consider ways to preserve compatibility. * We could introduce a soname change. Then the objects would link against the libstdc++ from their compile, and we wouldn't encounter trouble by mixing gcc versions. We might however run into trouble with precompiled code from other sources, and we'd also encounter problems if someone unmerges gcc 4.7, although preserved-libs might take care of serious problems for most users. * We could try to add the old name to the library, with the old functionality. Looking at the code from libstdc++-v3/src/c++11/chrono.cc, the functionality seems mostly the same, and in particular the ABI should be the same. See also http://repo.or.cz/w/official-gcc.git/commit/b354b404d1873970 for diffs. Also notice that the changes to compatibility-chrono.cc in that same commit include removal of some symbol version and alias magic, so we might build on that. * We should notify upstream of this issue, and could wait for them to come up with a proper fix. If someone can confirm that this is indeed likely to be an unintended ABI breakage and not caused by Gentoo, then I'll be happy to write that report for upstream.
(In reply to Martin von Gagern from comment #14) > * We should notify upstream of this issue […] Did so: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758 Looking at http://repo.or.cz/w/official-gcc.git/commit/bcc6e6bf7b9e20cf54988 I see that compatibility-chrono.cc would be the more appropriate source of that symbol. http://comments.gmane.org/gmane.comp.gcc.libstdc++.devel/25985 resp. https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01212.html might be worth reading for some background info. I haven't read it all yet, but it does go to some length discussing ABI compatibility.
OK, now I've found that this is probably a DELIBERATE breakage. Quoting https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01553.html: > If we want to care about C++11 ABI compat on release branches > (?), here's another solution. > > It scraps the renaming/aliasing approach, and just creates a > compatibility-chrono.cc that mimics the default configuration in 4.8.0. > Users who specially-configured a build with --enable-libstdcxx-time > configure options in 4.8.0 are breaking an experimental > C++ ABI anyway, so I'm not going to solve for anything but the default > case. So that's the point where the _V2 namespace was first considered. And it deliberately breaks backwards compatibility for an experimental ABI for those users who did some custom configuration. Unfortunately, Gentoo did do that custom configuration, in response to bug 411681. So it seems we are on our own.
Important for gcc-config maintainers! In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758#c2 a gcc dev wrote: > It is totally unsupported (and unlikely to work) to mix C++11 code > built with GCC 4.x and 4.y, for any x!=y So it seems to me as if the current Gentoo approach of using /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf to configure locations for e.g. libstdc++ is broken. Should I file a new bug report for this against gcc-config?
Created attachment 380508 [details, diff] Symver alias for gcc 4.8 GCC upstream emphasized that they won't support the Gentoo approach to handling libstdc++ for C++11, namely the use of a 4.8 libstdc++ with code compiled by 4.7. So we need to address this at the distro level, one way or another, at least until upstream officially declares its ABI stable. The attached patch restores the symbol in question by adding a symbol alias. The functionality of the new function is the same as for the old, except for a statically compiled fallback in those cases where the function was omitted altogether in the old code. I suggest you include my patch into gcc 4.8 before stabilizing that. That way you won't run into these switchover issues for stable users.
How does --enable-libstdcxx-time come into play here? It seems to me we shouldn't be enabling it these days. The reason for the current situation is that it's better than the previous alternative, where switching to an earlier version of gcc instantly broke any libstdc++-linked program that depended on symbol versions only available in the libstdc++ it was originally linked with (aka, in my experience, any libstdc++-linked program). It's not a particularly good solution, but it's what we got.
(In reply to Ryan Hill from comment #19) > How does --enable-libstdcxx-time come into play here? Enabling that setting allowed configure to auto-detect the availability of high-precision time functions, at least if they were available without linking in librt. If they were available, then the header would enable support for the steady_clock definition, and the library would export the corresponding symbol. So the symbol was configuration-dependent, which is a bad thing and part of the reason upstream decided to change things, as far as I can see. At least on systems where steady_clock is available, webkit will apparently make use of it, perhaps due to the fact that some synchronization primitives make use of it. I don't know what webkit would do in the absence of steady_clock. Mighte be they have some fall-back solution, but might also be they'd fail to build for lack of complete <thread> support. > It seems to me we shouldn't be enabling it these days. Not sure. For >=gcc-4.8 I agree, but for other versions it might cause situations where stuff compiled with a previous revision of gcc will suddenly fail with a newly emerged one. Not sure whether this affects any packages in portage except for this webkit one here, but it might also break user-compiled code. > The reason for the current situation is that it's better than the previous > alternative, where switching to an earlier version of gcc instantly broke > any libstdc++-linked program that depended on symbol versions only available > in the libstdc++ it was originally linked with (aka, in my experience, any > libstdc++-linked program). I can see how reordering ld.so.conf by gcc-config would be a bad idea. > It's not a particularly good solution, but it's what we got. Perhaps we can come up with some third solution? Things that I can think of: 1. Add the gcc minor version number to the SONAME of libstdc++. That way, each binary would link against the library against which it was compiled. We might still add the latest version with the SONAME chosen by upstream, to allow execution of precompiled binaries. 2. We could perhaps come up with some tool which checks the compatibility of installed versions of that library. Makes sure that the latest version of libstdc++ will provide all the symbols (with versions) of all the earlier instances with the same SONAME. We might run this tool between the install and the merge phase of the ebuild, to prevent merging a library which lacks backwards compatibility. Here is the kind of command I have in mind: diff -U0 <(objdump -T /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.4/libstdc++.so | awk '$4==".text"{print $7,$6}' | tr -d '()' | sort) <(objdump -T /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so | awk '$4==".text"{print $7,$6}' | tr -d '()' | sort) | tail -n+3 | grep ^- With my patch applied, the above command reports nothing. Comparing 4.6.4 to 4.7.4 I notice that _ZNSt6chrono15monotonic_clock3nowEv@GLIBCXX_3.4.11 went away. This is due to http://repo.or.cz/w/official-gcc.git/commit/cd9f496fd38314abcc660f35881b6658843706f0. Since this appears to be a rename only, we might add yet another alias like the one in my patch to provide compatibility with that as well. If neither of these solutions can be implemented, then we should take extra care at the distro level to ensure compatibility. So a tool like the one outlined above would be useful in any case, if only as a QA tool for maintainers.
*** Bug 512176 has been marked as a duplicate of this bug. ***
Since this is now officially blocking bug 461954 (gcc-4.8), please consider comment 18 for inclusion to fix this immediate problem. Gnome stabilization should in theory be unproblematic for stable-only users as they won't have a gcc 4.8 lying around at all. But it would be nice to have a compatible gcc 4.8 in tree anyway, so we are committed to providing that ABI and don't break stable systems with a gcc upgrade later on.
We would also need the a patch (or fix) for 4.9 as Ago confirmed the problem with 4.9 too
*** Bug 517760 has been marked as a duplicate of this bug. ***
(In reply to Pacho Ramos from comment #23) > We would also need the a patch (or fix) for 4.9 as Ago confirmed the problem > with 4.9 too Since upstream indicated that they don't intend to provide ABI compatibility here, we'll have to maintain that in Gentoo at least until we no longer support binaries compiled with gcc 4.7. Seeing how we still have ancient versions of gcc in portage right now, that may be a really long time, so I'd expect this patch will be going to stay quite a while.
*** Bug 522308 has been marked as a duplicate of this bug. ***
Can anyone still reproduce with 2.4.4-r200? I couldn't, tested with gcc-4.8, fresh install of webkit-gtk.
(In reply to Paweł Hajdan, Jr. from comment #27) > Can anyone still reproduce with 2.4.4-r200? I couldn't, tested with gcc-4.8, > fresh install of webkit-gtk. Are you sure you're testing it correctly ? It can be reproduced even with 2.4.5. After all, it's not a webkit-gtk problem, it's a Gentoo problem.
This issue has not occurred for me for quite some time. Currently have webkit-gtk-2.4.4-r200 and gcc-4.8.3. I don't recall what has changed locally to cause this to stop occurring for me, but it hasn't been an issue for a couple of months. However it is apparent that many people still experience this issue, so I would certainly not close the bug.
This problem is trivial to reproduce. 1. Have 4.7 and 4.8 installed, 4.7 selected as active. 2. compile webkit-gtk - get the failure. Reiterating the explanation from comment 12: gcc ebuild adds /etc/ld.so.conf.d/05gcc-i686-pc-linux-gnu.conf entries, sorted by version. During compilation, API from *active* version is used. During linking, ABI from the first *listed* version is used. If those two disagree, like it's the case here for c++11, you'll getting various funny results. The problem here seems to be, that due to clang, c++11 features came into active use *before* gcc decided to mark them as stable. Binary distros/MacOSX deal with it by "rebuild all, then stick to that version" means, but it bites us us here. Other than switching the active version, the workaround some used here was to edit 05gcc-i686-pc-linux-gnu.conf so that the needed version comes first. Obviously, this sticks only till next gcc emerge.
*** Bug 524160 has been marked as a duplicate of this bug. ***
(In reply to Rafał Mużyło from comment #30) > This problem is trivial to reproduce. > > 1. Have 4.7 and 4.8 installed, 4.7 selected as active. > 2. compile webkit-gtk - get the failure. > > Reiterating the explanation from comment 12: > gcc ebuild adds /etc/ld.so.conf.d/05gcc-i686-pc-linux-gnu.conf entries, > sorted by version. > During compilation, API from *active* version is used. > During linking, ABI from the first *listed* version is used. Ah you're right, thanks for the explanation! I can indeed repro this now on a stable amd64 system with gcc-config-1.7.3.
(In reply to Rafał Mużyło from comment #30) > Other than switching the active version, the workaround some used here was > to edit 05gcc-i686-pc-linux-gnu.conf so that the needed version comes first. Personally I'm happily using my patch from comment #18. Would feedback from others doing the same be of any use here? If so, please ask for it. Otherwise, I'd be very interested to get some kind of response for that suggested patch, whether you are considering it for inclusion or have reasons not to do so.
I have a similar issue on arm only, not sure if root cause is the same. This only links correctly without introspection/gstreamer (not a good workaround). The system is build from a recent stage3 and toolchain upgraded (gcc 4.7.3 -> 4.8.3, glibc -> 2.19). From the discussion here, I can't see anywhere (in my case) that 4.7 could take precedence over 4.8, except for the fact that 4.7 is still installed. Thoughts? New bug? [ebuild R ] net-libs/webkit-gtk-2.4.4:3/25::arm_support USE="X egl geoloc* gles2 gstreamer* introspection* libsecret spell wayland webkit1 (-aqua) -coverage -debug -jit -opengl {-test} -webgl" With USE=introspection, it always fails with: /var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/tmp-introspectdYyYBW/.libs/lt-WebKit-3.0: /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by /var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/.libs/libwebkitgtk-3.0.so.0) /var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/tmp-introspectdYyYBW/.libs/lt-WebKit-3.0: /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by /var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/.libs/libjavascriptcoregtk-3.0.so.0) Command '['/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/tmp-introspectdYyYBW/WebKit-3.0', '--introspect-dump=/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/tmp-introspectdYyYBW/functions.txt,/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4/tmp-introspectdYyYBW/dump.xml']' returned non-zero exit status 1 GNUmakefile:82183: recipe for target 'WebKit-3.0.gir' failed make[1]: *** [WebKit-3.0.gir] Error 1 make[1]: *** Waiting for unfinished jobs.... libtool: link: (cd ".libs" && rm -f "libwebkit2gtk-3.0.so.25" && ln -s "libwebkit2gtk-3.0.so.25.10.7" "libwebkit2gtk-3.0.so.25") libtool: link: (cd ".libs" && rm -f "libwebkit2gtk-3.0.so" && ln -s "libwebkit2gtk-3.0.so.25.10.7" "libwebkit2gtk-3.0.so") libtool: link: ( cd ".libs" && rm -f "libwebkit2gtk-3.0.la" && ln -s "../libwebkit2gtk-3.0.la" "libwebkit2gtk-3.0.la" ) make[1]: Leaving directory '/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4' GNUmakefile:25561: recipe for target 'all' failed make: *** [all] Error 2 * ERROR: net-libs/webkit-gtk-2.4.4::arm_support failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=net-libs/webkit-gtk-2.4.4::arm_support'`, * the complete build log and the output of `emerge -pqv '=net-libs/webkit-gtk-2.4.4::arm_support'`. * The complete build log is located at '/var/log/portage/net-libs:webkit-gtk-2.4.4:20141002-064251.log'. * For convenience, a symlink to the build log is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-libs/webkit-gtk-2.4.4/temp/environment'. * Working directory: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4' * S: '/var/tmp/portage/net-libs/webkit-gtk-2.4.4/work/webkitgtk-2.4.4' Portage 2.2.12 (python 2.7.8-final-0, default/linux/arm/13.0/armv7a/desktop, gcc-4.8.3, glibc-2.19-r1, 3.16.3-armv7-x4-00237-gd472049 armv7l) ================================================================= System uname: Linux-3.16.3-armv7-x4-00237-gd472049-armv7l-with-gentoo-2.2 KiB Mem: 2063388 total, 931188 free KiB Swap: 1310712 total, 1298348 free Timestamp of tree: Tue, 16 Sep 2014 09:45:01 +0000 ld GNU ld (Gentoo 2.24 p1.4) 2.24 distcc 3.1 armv7a-hardfloat-linux-gnueabi [enabled] ccache version 3.1.9 [enabled] app-shells/bash: 4.2_p47 dev-lang/python: 2.7.8, 3.2.5-r1, 3.3.5-r1, 3.4.1 dev-util/ccache: 3.1.9-r3 dev-util/cmake: 3.0.2 dev-util/pkgconfig: 0.28-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.13.1 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.14.1 sys-devel/binutils: 2.24-r3 sys-devel/gcc: 4.6.4, 4.7.3, 4.8.3 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2-r1 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.14 (virtual/os-headers) sys-libs/glibc: 2.19-r1 Repositories: gentoo nerdboy-local arm_support ACCEPT_KEYWORDS="arm ~arm" ACCEPT_LICENSE="* -@EULA @GPL-COMPATIBLE @OSI-APPROVED @EULA dlj-1.1 skype-eula googleearth AdobeFlash-10.1 Oracle-BCLA-JavaSE" CBUILD="armv7a-hardfloat-linux-gnueabi" CFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" CHOST="armv7a-hardfloat-linux-gnueabi" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe -march=armv7-a" FEATURES="assume-digests binpkg-logs buildpkg ccache config-protect-if-modified distcc distlocks ebuild-locks fixlafiles merge-sync news nodoc parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe -march=armv7-a" GENTOO_MIRRORS="http://XXX.XXX.XXX.XXX/gentoo/" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j15" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/arm" SYNC="rsync://XXX.XXX.XXX.XXX/gentoo-portage" USE="X a52 aac abiword acl acpi alsa arm aspell audiofile avahi berkdb bindist bitmap-fonts bluetooth branding bzip2 cairo caps cdda cdr cli consolekit cracklib crypt cups cxx dbus dri drm dts dvd dvdr egl emboss enchant encode etnaviv exif fam firefox flac fortran freetype freetype2 gbm gcj gd gdbm gif gles1 gles2 glib gnome-keyring go gpm gstreamer gtk gudev highlight iconv id3tag imlib inotify introspection ipv6 jpeg lame lcms ldap libcanberra libnotify libsamplerate libsecret lua mad mng modules mp3 mp4 mpeg ncurses neon nls nptl ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio python qt3support readline ruby sdl session sexy spell sqlite ssl startup-notification svg system-cairo system-jpeg system-sqlite tcpd tiff truetype truetype-fonts type1-fonts udev udisks unicode upower usb v4l vala vorbis wayland webkit wifi wxwidgets xattr xcb xdg xml xorg xrandr xv xvid zeroconf zlib" ALSA_CARDS="usb-audio" APACHE2_MODULES="actions alias auth_digest auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_connect proxy_http rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CURL_SSL="openssl" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en_US en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python3_4 python3_3 python2_7" RUBY_TARGETS="ruby21 ruby20" USERLAND="GNU" VIDEO_CARDS="fbdev etnaviv modesetting" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" USE_PYTHON="2.7 3.3 3.4" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to Steve Arnold from comment #34) > I have a similar issue on arm only, not sure if root cause is the same. > This only links correctly without introspection/gstreamer (not a good > workaround). The system is build from a recent stage3 and toolchain > upgraded (gcc 4.7.3 -> 4.8.3, glibc -> 2.19). From the discussion here, I > can't see anywhere (in my case) that 4.7 could take precedence over 4.8, > except for the fact that 4.7 is still installed. Thoughts? New bug? > > /usr/lib/gcc/armv7a-hardfloat-linux-gnueabi/4.7.3/libstdc++.so.6: > version `GLIBCXX_3.4.19' not found This error message looks like the converse problem. Where this bug here is about code compiled with gcc 4.7 but linked with 4.8, the error you report looks like the opposite thing: GLIBCXX_3.4.19 contains the std::chrono::_V2 inline namespace introduced by gcc 4.8, so apparently the code was compiled by 4.8 but the symbols in question can't be found at link time. Definitely related, but also not the same cause. Perhaps ldconfig didn't work correctly on your system? In any case, I'd say this is a new but related bug.
Yup, in this case the core libs appear to link against the correct/active libstdc++ (gcc) but the introspection gir-lib stuff (wth that is) tries to link against the 4.7.3 lib instead. Why? I have no idea yet... The active (4.8.3) version is listed first in ld.so config snippet, and the env.d/gcc stuff also looks correct. The 4.8.3/2.19 toolchain has been rebuilt with itself (ie, everything with 4.8.3) so at this point I'm stumped...
So, manually removing the older gcc versions from 05gcc-armv7a-hardfloat-linux-gnueabi.conf and running ldconfig makes webkit-gtk all happy again, at least wrt the introspection/gstreamer stuff. It just takes several hours to find out... Anyway, so far this is the only package with this issue on arm; wonky build systems aside, what's the appropriate action here?
sorry to interrupt you Steve but the gstreamer issue seams to have a predecessor: https://bugs.gentoo.org/show_bug.cgi?id=372493 found here: https://forums.freebsd.org/viewtopic.php?&t=25970 seemed to me first irrelevant regarding the dates but now when i came across your points it seemed to me to be worth of mentioning it.
I have the same problem here but with zenity: [ebuild U ~] gnome-extra/zenity-3.14.0::gnome [3.12.1::gentoo] USE="libnotify webkit -debug {-test}" 0 kB x86_64-pc-linux-gnu-gcc -pthread -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -pthread -I/usr/include/webkitgtk-3.0 -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/webkitgtk-3.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -Wall -march=native -O2 -pipe -Wl,-O1 -Wl,--as-needed -o zenity zenity-about.o zenity-calendar.o zenity-entry.o zenity-fileselection.o zenity-main.o zenity-msg.o zenity-notification.o zenity-option.o zenity-progress.o zenity-scale.o zenity-text.o zenity-tree.o zenity-color.o zenity-password.o zenity-util.o zenity-forms.o -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lX11 -lnotify -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lwebkitgtk-3.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 -lgobject-2.0 -ljavascriptcoregtk-3.0 -lglib-2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../lib64/libwebkitgtk-3.0.so: undefined reference to `std::chrono::steady_clock::now()@GLIBCXX_3.4.17'
@comment 39: Actually, that's the exact *opposite* of this problem, in a way. It this case, webkit-gtk was built with gcc 4.7, then a gcc-config switch to 4.8 was made. As libstdc++ from 4.8 doesn't have this symbol, the build failure is the expected result. You most likely need to rebuild webkit-gtk with 4.8. Again the question arises if gcc upstream has already marked c++11 features as ABI stable (and if so, on which branch) or are we to expect similar failures in the near future.
(In reply to Rafał Mużyło from comment #30) > This problem is trivial to reproduce. > > 1. Have 4.7 and 4.8 installed, 4.7 selected as active. > 2. compile webkit-gtk - get the failure. > > Reiterating the explanation from comment 12: > gcc ebuild adds /etc/ld.so.conf.d/05gcc-i686-pc-linux-gnu.conf entries, > sorted by version. > During compilation, API from *active* version is used. > During linking, ABI from the first *listed* version is used. > > If those two disagree, like it's the case here for c++11, you'll getting > various funny results. > > The problem here seems to be, that due to clang, c++11 features came into > active use *before* gcc decided to mark them as stable. > > Binary distros/MacOSX deal with it by "rebuild all, then stick to that > version" means, but it bites us us here. > > Other than switching the active version, the workaround some used here was > to edit 05gcc-i686-pc-linux-gnu.conf so that the needed version comes first. > Obviously, this sticks only till next gcc emerge. Do you know why the order is not reversed then to try to use newer one first? Thanks for the info :)
(In reply to Pacho Ramos from comment #41) the gcc ld.so.conf sorting behavior is correct. it must be ABI stable. note: please don't quote the full message when you aren't using it ... makes it hard to read bugs with all the spam
*** Bug 526974 has been marked as a duplicate of this bug. ***
*** Bug 527070 has been marked as a duplicate of this bug. ***
My issue marked as a duplicate of this issue. But I don't have any issues with recompilation of webkit-gtk. But I can't recompile evolution which depends on webkit-gtk.
*** Bug 527096 has been marked as a duplicate of this bug. ***
After emerge -C webkit-gtk & evolution And re-emerging them again, everything works fine now.
(In reply to SpanKY from comment #42) OK, thanks for the info. And do you know if would be possible to for one ebuild to use gcc:4.8 ABI instead of the older one even without touching the order in ld.so.conf for the rest?
Enews item 2014-10-26-gcc_4_7_introduced_new_c++11_abi made users aware of the danger of ABI incompatibilities due to unstabel C++11 ABI. That's nice. However, what does this enews mean for the bug at hand? Do you want to leave problems to the users (“you've been told things will break”), or will you consider fixing this specific problem using the patch from comment #18? In comment #33 I requested info on the status of that patch. I'm still waiting for that answer from gcc maintainers.
I found this bug is difficult to circumvent because there were actually two versions of webkit-gtk installed. Remerging the package always selected the wrong one, and the problem did not go away. I did emerge -av -C webkit-gtk epiphany # removes all webkit-gtk versions emerge -tv epiphany and now epiphany works again.
(In reply to Pacho Ramos from comment #48) it is using the ABI at link time which is the problem isn't it ? the gcc-4.8 ABI is not compatible with gcc-4.9 ABI. there isn't a way to control the ABI used at runtime. i don't think we should support this.
On my Gentoo box primarily for test purposes I have two webkit browsers. Previous system update, when was stabilized and installed sys-devel/gcc:4.8 made my webkit browsers inoperable. =www-client/uzbl-2012.05.14 failed to start at all: $ uzbl-browser uzbl-core: relocation error: /usr/lib64/libwebkitgtk-1.0.so.0: symbol _ZNSt6chrono12steady_clock3nowEv, version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time reference $ equery b /usr/lib64/libwebkitgtk-1.0.so.0 * Searching for /usr/lib64/libwebkitgtk-1.0.so.0 ... net-libs/webkit-gtk-2.4.4-r201 (/usr/lib64/libwebkitgtk-1.0.so.0.22.10) =www-client/midori-0.5.8-r1 starts, but fails to open any url echoing into stderr: /usr/libexec/WebKitWebProcess: relocation error: /usr/lib64/libwebkit2gtk-3.0.so.25: symbol _ZNSt6chrono12steady_clock3nowEv, version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time reference $ equery b /usr/lib64/libwebkit2gtk-3.0.so.25 * Searching for /usr/lib64/libwebkit2gtk-3.0.so.25 ... net-libs/webkit-gtk-2.4.4-r1 (/usr/lib64/libwebkit2gtk-3.0.so.25 -> libwebkit2gtk-3.0.so.25.10.7) On that update were installed: Sat Oct 25 11:23:08 2014 >>> app-misc/pax-utils-0.8.1 Sat Oct 25 11:23:36 2014 >>> media-libs/jasper-1.900.1-r6 Sat Oct 25 11:24:10 2014 >>> dev-libs/libgcrypt-1.5.4-r1 Sat Oct 25 11:24:44 2014 >>> media-libs/alsa-lib-1.0.28 Sat Oct 25 11:25:10 2014 >>> media-libs/libmikmod-3.3.6-r1 Sat Oct 25 11:25:24 2014 >>> media-libs/sdl-mixer-1.2.12-r4 Sat Oct 25 11:25:38 2014 >>> media-libs/sdl-image-1.2.12-r1 Sat Oct 25 11:25:56 2014 >>> media-sound/alsa-utils-1.0.28 Sat Oct 25 11:26:06 2014 >>> dev-lua/luasocket-3.0_rc1-r3 Sat Oct 25 12:14:18 2014 >>> sys-devel/gcc-4.8.3 Sat Oct 25 12:14:33 2014 >>> dev-libs/popt-1.16-r2 Sat Oct 25 12:14:50 2014 >>> net-libs/libpcap-1.6.2-r1 Sat Oct 25 12:15:13 2014 >>> net-analyzer/tcpdump-4.6.2 Active gcc after update still 4.7: # gcc-config -l [1] x86_64-pc-linux-gnu-4.7.3 * [2] x86_64-pc-linux-gnu-4.8.3 Unmerge the =sys-devel/gcc:4.8 made my webkit browsers operable again.
(In reply to SpanKY from comment #51) > (In reply to Pacho Ramos from comment #48) > > it is using the ABI at link time which is the problem isn't it ? the > gcc-4.8 ABI is not compatible with gcc-4.9 ABI. > > there isn't a way to control the ABI used at runtime. i don't think we > should support this. Why not to make ld.so to search the active gcc version path before other versions? e.g. you can just add/modify the /etc/ld.so.conf/04active-gcc-arch.conf during gcc-config or whatever and notice if it's missing during gcc merge. I suppose that now, when the gcc-4.8 is already marked stable, the number of users who will increase a lot...
(In reply to Fat-Zer from comment #53) because then every time you change the active gcc version, you take the risk of breaking literally every C++ app on your system. see bug 297685.
Then, I guess we cannot do much more than asking people (not sure in what way, news item?) to switch to newer gcc as soon as possible to be able to recompile webkit-gtk. We would also need a way to detect relocation failures as people currently need to know they need to recompile webkit-gtk due that (and this could affect to other packages that I am still not aware about). Sadly revdep-rebuild doesn't allow yet to detect this kind of issues (#63643, well, maybe https://bugs.gentoo.org/show_bug.cgi?id=162589#c17 approach could help) and, then, probably rebuilding every package linking to the cxx lib is the way to go (even it causing to rebuild more packages than needed) with revdep-rebuild --library 'libstdc\+\+.so.6'
(In reply to SpanKY from comment #54) > because then every time you change the active gcc version, you take the risk > of breaking literally every C++ app on your system. see bug 297685. To my mind this warning, together with described in this bug ld.so.conf issue worths to be documented in https://wiki.gentoo.org/wiki/Upgrading_GCC#Introduction I don't do it because my English is awful. (In reply to Pacho Ramos from comment #55) > Then, I guess we cannot do much more than asking people (not sure in what > way, news item?) to switch to newer gcc as soon as possible to be able to > recompile webkit-gtk. Is it (recomendation to switch on newer version of gcc as soon as possible) a common one? If so, could you document it in quoted article (maybe, together with issue)?
I encountered this bug after a system update required that webkit-gtk-2.4.4-r201 be rebuilt. My system gcc is gcc-4.7.3 and gcc-4.8.3 is installed and thus the failure. I tried the patch (https://bugs.gentoo.org/attachment.cgi?id=380508) under https://bugs.gentoo.org/show_bug.cgi?id=513386#c18 and rebuilt gcc-4.8.3. I don't see the undefined reference failure but now the build just hangs (stops doing anything) with ./Source/WebKit/gtk/webkit/*.cpp Source/WebKit/gtk/webkit/webkitversion.h:37: Warning: WebKit: symbol='WEBKITGTK_API_VERSION': Unknown namespace for symbol 'WEBKITGTK_API_VERSION' These are the lines from webkitversion.h /** * WEBKITGTK_API_VERSION: (skip) */ #define WEBKITGTK_API_VERSION (1.0) <== line 37 So perhaps something more subtle is up?
(In reply to Martin von Gagern from comment #49) > Enews item 2014-10-26-gcc_4_7_introduced_new_c++11_abi made users aware of > the danger of ABI incompatibilities due to unstable C++11 ABI. That's nice. > > However, what does this enews mean for the bug at hand? Do you want to leave > problems to the users (“you've been told things will break”), or will you > consider fixing this specific problem using the patch from comment #18? I missed that on first reading, but it's *exactly* what is needed, imo (though I was thinking a weak alias, weakref in gcc terms iirc; not sure how the symver works out, it looks like a strong symbol. Not that it really matters.) It simply maintains compatibility on Gentoo installs for the already published ABI, and thus is precisely right, afaic. The only possible issue it could have is when transferring a binary made on Gentoo to another system, but if you're doing that you're most likely commercial and can sort it out yourself; even if it weren't such an unlikely thing to be doing, as against simply distributing source. (and it would only be an issue where you're already going to have an issue, ie C11 objects built before the new version, which also use the symbol.) At least let's start testing this patch out, to prove that it needs work, and why, if we're not prepared to just use it as-is. It seems pretty uncontroversial to my eyes (even if I don't like all the *_HAVE* they are already part of autoconf setup), and simply maintains glibc compatibility, as upstream should have done all along, again imo.
(In reply to Steven Trogdon from comment #57) > I encountered this bug after a system update required that > webkit-gtk-2.4.4-r201 be rebuilt. My system gcc is gcc-4.7.3 and gcc-4.8.3 > is installed and thus the failure. I tried the patch > (https://bugs.gentoo.org/attachment.cgi?id=380508) under > https://bugs.gentoo.org/show_bug.cgi?id=513386#c18 and rebuilt gcc-4.8.3. I > don't see the undefined reference failure but now the build just hangs > (stops doing anything) with > > ./Source/WebKit/gtk/webkit/*.cpp > Source/WebKit/gtk/webkit/webkitversion.h:37: Warning: WebKit: > symbol='WEBKITGTK_API_VERSION': Unknown namespace for symbol > 'WEBKITGTK_API_VERSION' > > These are the lines from webkitversion.h > > /** > * WEBKITGTK_API_VERSION: (skip) > */ > #define WEBKITGTK_API_VERSION (1.0) <== line 37 > > So perhaps something more subtle is up? This hang was a result of Bug #463960. After dealing with that issue webkit-gtk-2.4.2-r201 now builds here with system gcc-4.7.3 and gcc-4.8.3 installed and patched with https://bugs.gentoo.org/attachment.cgi?id=380508
*** Bug 529658 has been marked as a duplicate of this bug. ***
(In reply to Martin von Gagern from comment #18) > Created attachment 380508 [details, diff] [details, diff] > Symver alias for gcc 4.8 > > GCC upstream emphasized that they won't support the Gentoo approach to > handling libstdc++ for C++11, namely the use of a 4.8 libstdc++ with code > compiled by 4.7. So we need to address this at the distro level, one way or > another, at least until upstream officially declares its ABI stable. > > The attached patch restores the symbol in question by adding a symbol alias. > The functionality of the new function is the same as for the old, except for > a statically compiled fallback in those cases where the function was omitted > altogether in the old code. > > I suggest you include my patch into gcc 4.8 before stabilizing that. That > way you won't run into these switchover issues for stable users. Simple question: How do I install this patch?
(In reply to Joseph from comment #61) > Simple question: How do I install this patch? Simple answer: to try this (or any other custom patch) use epatch_user function. https://wiki.gentoo.org/wiki//etc/portage/patches
(In reply to Sergey S. Starikoff from comment #52) [snip] > # gcc-config -l > [1] x86_64-pc-linux-gnu-4.7.3 * > [2] x86_64-pc-linux-gnu-4.8.3 > > Unmerge the =sys-devel/gcc:4.8 made my webkit browsers operable again. unmerging =sys-devel/gcc-4.8.3 did not help me. I'm still getting an error with rubby: setproctitle.o addr2line.o dmyext.o -lpthread -lrt -ldl -lcrypt -lm -o miniruby ./miniruby -I./lib -I. -I.ext/common ./tool/mkconfig.rb -timestamp=.rbconfig.time \ -install_name=ruby20 \ -so_name=ruby20 rbconfig.rb uncommon.mk:528: recipe for target '.rbconfig.time' failed make: *** [.rbconfig.time] Illegal instruction * ERROR: dev-lang/ruby-2.0.0_p594::gentoo failed (compile phase): * emake failed
(In reply to Sergey S. Starikoff from comment #62) > (In reply to Joseph from comment #61) > > Simple question: How do I install this patch? > > Simple answer: to try this (or any other custom patch) use epatch_user > function. https://wiki.gentoo.org/wiki//etc/portage/patches In this case, it's probably best to apply the patch to specific slots, namely 4.8 and 4.9. You can do that in the following way: # mkdir -p /etc/portage/patches/sys-devel/gcc:4.8 # wget -O /etc/portage/patches/sys-devel/gcc:4.8/gentoo513386a.patch \ 'https://bugs.gentoo.org/attachment.cgi?id=380508' # emerge -1 sys-devel/gcc:4.8 and likewise for 4.9. (In reply to Steve L from comment #58) > (though I was thinking a weak alias, weakref in gcc terms iirc; not sure how > the symver works out, it looks like a strong symbol. Not that it really > matters.) It's a strong symbol, but a versioned one, without a default version. (A default version would have had a double @@ instead of the single @.) So the symbol will only be used to satisfy versioned symbol dependencies from already compiled code, but will never be used when compiling new code. So it's really only providing ABI compatibility for code compiled against a different version, and won't affect API or ABI for stuff compiled with consistent GCC versions. > (even if I don't like all the *_HAVE* they are already part of autoconf setup) This was taken from http://repo.or.cz/w/official-gcc.git/blob/bcc6e6bf7b9e20cf54988a55be2ae5fae889d813:/libstdc%2B%2B-v3/src/c%2B%2B11/compatibility-chrono.cc where they had some symbol aliases in place at some point. > as upstream should have done all along, again imo. *nod*. It would have been so easy… On the other hand, at least upstream made it VERY clear that they won't fix this issue, and they have some valid reasons why this is a Gentoo problem: the mixed versions, the use of experimental C++11 in not-so-experimental code and the use of the non-standard configure switch --enable-libstdcxx-time. The fact that Gentoo's gcc maintainers still haven't responded to this proposed patch in any way is in a certain way more frustrating, since I don't even know what's keeping them from simply applying the patch. Why do they issue an enews item warning about a potential problem instead of investigating ways to avoid said problem? Or, if they have investigated those ways, why not share their findings?
(In reply to Joseph from comment #63) > unmerging =sys-devel/gcc-4.8.3 did not help me. > I'm still getting an error with rubby: > > setproctitle.o addr2line.o dmyext.o -lpthread -lrt -ldl -lcrypt -lm -o > miniruby > ./miniruby -I./lib -I. -I.ext/common ./tool/mkconfig.rb > -timestamp=.rbconfig.time \ > -install_name=ruby20 \ > -so_name=ruby20 rbconfig.rb > uncommon.mk:528: recipe for target '.rbconfig.time' failed > make: *** [.rbconfig.time] Illegal instruction > * ERROR: dev-lang/ruby-2.0.0_p594::gentoo failed (compile phase): > * emake failed Probably that is another issue. For now I've switched to gcc:4.8. On last update (the described system) I've got a strange issue with building net-libs/webkit-gtk. Switching to 4.8 (with libtool rebuild) and repeat made this issue go away, so I've don't analyzed that build log. AFAIR discussion mentioned, that usage of multiple gcc versions is not a standard one. So switching to new one is strictly recommended for most ordinar users.
@comment 64: The answer of one of those questions is quite simple: as noted on -dev mailing list, gcc maintainer has stepped down recently, so things are still in flux there. @comment 63: That's almost certainly completely unrelated and most likely either not even a compiler bug but either a problem with your C{XX}FLAGS or that little ruby problem, that should already have a fix in the tree for both 2.0 and 2.1.
*** Bug 535728 has been marked as a duplicate of this bug. ***
Can't reproduce for gcc-4.9.2 - looks like fixed.
Same issue appears when upgrading from 4.7.3 to 4.8.4. https://bugs.gentoo.org/attachment.cgi?id=380508 patch fixes it.
(In reply to Martin von Gagern from comment #18) > Created attachment 380508 [details, diff] [details, diff] > Symver alias for gcc 4.8 > > GCC upstream emphasized that they won't support the Gentoo approach to > handling libstdc++ for C++11, namely the use of a 4.8 libstdc++ with code > compiled by 4.7. So we need to address this at the distro level, one way or > another, at least until upstream officially declares its ABI stable. > > The attached patch restores the symbol in question by adding a symbol alias. > The functionality of the new function is the same as for the old, except for > a statically compiled fallback in those cases where the function was omitted > altogether in the old code. > > I suggest you include my patch into gcc 4.8 before stabilizing that. That > way you won't run into these switchover issues for stable users. Just to say that this patch saved my life, thanks! I had a very hard time upgrading my ia64 workstation to gnome 3.16 because of >=net-libs/webkit-gtk-2.8 no more building on ia64 (bug #555504). Once I worked around this problem successfully building webkit-gtk with vanilla gcc 4.8, I then experienced the issue reported here with yelp and evolution (built with ia64 stable gcc 4.7). Rebuilding them with vanilla gcc 4.8 didn't solve the problem, despite /etc/ld.so.conf.d/05gcc-ia64-unknown-linux-gnu.conf listing /usr/lib/gcc/ia64-unknown-linux-gnu/4.8.5 first and ldd /usr/lib/libwebkitgtk-3.0.so linking against /usr/lib/gcc/ia64-unknown-linux-gnu/4.8.5/libstdc++.so.6. Rebuilding all three webkit-gtk, yelp and evolution them with patched gcc 4.8 fixed the problem. Émeric
Hi, Now that gcc 4.9 is ia64 stable, I'm running this issue again with =net-libs/webkit-gtk-2.10.7. By contrast to what I did have in comment #70, I've rebuilt my whole system with gcc 4.9 with emerge -eav system ; emerge -eav world to fix it. No go: both =mail-client/evolution-3.18.14 and =net-im/empathy-3.12.11 are failing with: /usr/lib/gcc/ia64-unknown-linux-gnu/4.9.3/../../../libwebkitgtk-3.0.so: undefined reference to `std::chrono::steady_clock::now()@GLIBCXX_3.4.17' Do we still have to patch gcc >= 4.8 with attachment #380508 [details, diff] to work around this issue? Émeric
i can't really verify as ruby looks broken on ia64, and webkit (for some reason) requires ruby in order to build at any rate, the fact you have a lib still referring to that symbol implies that you either need to relink the lib or make sure you're using the right version of gcc in the process. you can try unmerging webkit-gtk entirely to be sure, and make sure you get the correct version/slot that actually installs libwebkitgtk-3.0.so.
(In reply to SpanKY from comment #72) > i can't really verify as ruby looks broken on ia64, and webkit (for some > reason) requires ruby in order to build You can work around this by reworking the part of WebKit-GTK's ebuild that look for Ruby interpreter to use (deprecated) Ruby 1.9. This is what I did in attachment #416040 [details]. > at any rate, the fact you have a lib still referring to that symbol implies > that you either need to relink the lib or make sure you're using the right > version of gcc in the process. you can try unmerging webkit-gtk entirely to > be sure, and make sure you get the correct version/slot that actually > installs libwebkitgtk-3.0.so. Aha, unmerging did the trick, thanks. In fact, both webkit-gtk-2.4.9.r1 and webkit-gtk-2.10.7 were unmerged. The unresolved symbol error didn't come from webkit-gtk-2.10.7 (slot 4, /usr/lib/gcc/ia64-unknown-linux-gnu/4.9.3/../../../libwebkitgtk-4.0.so) but webkit-gtk-2.4.9-r1 (slot 3, /usr/lib/gcc/ia64-unknown-linux-gnu/4.9.3/../../../libwebkitgtk-3.0.so). I didn't noticed it. Strange, as I've rebuilt my whole system with emerge -eav system; emerge -eav world. So it appears that net-libs/webkit-gtk:3 wasn't rebuilt. Does it mean that emerge -eav system; emerge -eav world has rebuilt only latest slot of each package (net-libs/webkit-gtk:4 in the present case)? Émeric [1] https://bugs.gentoo.org/attachment.cgi?id=416040
Ah, I now see vapier closed it... are you sure this was fixed? At least on webkit-gtk side we haven't change anything... and it's not clear to me what has changed in gcc ebuilds for handling this problem with "chronosteady" :/
the "fix" was the same as others in cases like this ... need to rebuild libs w/newer gcc versions webkit made things a little confusing/weird in that it has multiple SLOTs, so even if you did `emerge webkit-gtk`, your old SLOT would still be broken.
(In reply to SpanKY from comment #75) > the "fix" was the same as others in cases like this ... need to rebuild libs > w/newer gcc versions > I'd argue that more correct status would be OBSOLETE, as with gcc 5.3 (once things finally clear up there) full libstdc++ rebuild will be inevitable one way or another.
(In reply to Rafał Mużyło from comment #76) you can argue for many of the different statuses. they're all just as "accurate", but in the end, a meaningless distinction.
OK thanks, I wanted to know what was the final "solution" for the case someone hits this again and before gcc5.x hits stable ;)
