Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 512176 - net-libs/webkit-gtk-2.4.3 building fails with gcc 4.7
Summary: net-libs/webkit-gtk-2.4.3 building fails with gcc 4.7
Status: RESOLVED DUPLICATE of bug 513386
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] GNOME (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-02 17:22 UTC by Jonas Maaskola
Modified: 2014-07-21 12:49 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Build log (partial: first and last 1000 lines) (build.log.part.gz,72.71 KB, application/gzip)
2014-06-02 17:28 UTC, Jonas Maaskola
Details
Build log (partial: first and last 1000 lines) (build.log.part.bz2,47.53 KB, application/x-bzip2)
2014-06-02 17:34 UTC, Jonas Maaskola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Maaskola 2014-06-02 17:22:59 UTC
Building net-libs/webit-gtk-2.4.3 should likely require usage of gcc 4.8 for C++11 features.


Reproducible: Always

Steps to Reproduce:
1. gcc-config x86_64-pc-linux-gnu-4.7.3
2. emerge =net-libs/webkit-gtk-2.4.3

Actual Results:  
Building fails during linking with gcc 4.7.3 with

./.libs/libwebkitgtk-3.0.so: undefined reference to `_ZNSt6chrono12steady_clock3nowEv@GLIBCXX_3.4.17'

c++filt unmangling, this symobl is: std::chrono::steady_clock::now()

Expected Results:  
Linking should not fail

As reported [1], linking a minimal program with this C++11 routine using gcc 4.7.3-4 fails on debian, but succeeds with gcc 4.8.

Also here on Gentoo, building net-libs/webkit-gtk-2.4.3 succeeds with these steps:
1. x86_64-pc-linux-gnu-4.8.2
2. emerge =net-libs/webkit-gtk-2.4.3

[1] https://lists.debian.org/debian-gcc/2013/07/msg00039.html
Comment 1 Jonas Maaskola 2014-06-02 17:28:32 UTC
Created attachment 378078 [details]
Build log (partial: first and last 1000 lines)
Comment 2 Jonas Maaskola 2014-06-02 17:34:10 UTC
Created attachment 378080 [details]
Build log (partial: first and last 1000 lines)

I messed-up the compression of the first attachment
Comment 3 Jonas Maaskola 2014-06-02 17:42:28 UTC
Portage 2.2.8-r1 (default/linux/amd64/13.0/desktop/gnome/systemd, gcc-4.7.3, glibc-2.17, 3.14.4-gentoo x86_64)
=================================================================
System uname: Linux-3.14.4-gentoo-x86_64-Intel-R-_Core-TM-_i7-4770K_CPU_@_3.50GHz-with-gentoo-2.2
KiB Mem:     7860172 total,   3481460 free
KiB Swap:   20971516 total,  20786244 free
Timestamp of tree: Mon, 02 Jun 2014 16:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.2
app-shells/bash:          4.2_p45
dev-java/java-config:     2.2.0
dev-lang/python:          2.7.6, 3.2.5-r3, 3.3.3
dev-util/cmake:           2.8.12.2
dev-util/pkgconfig:       0.28
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
sys-devel/binutils:       2.23.2
sys-devel/gcc:            4.7.3-r1, 4.8.2
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.13 (virtual/os-headers)
sys-libs/glibc:           2.17
Repositories: gentoo gamerlay gentoo-haskell qt sunrise x-portage
Installed sets: @steam
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
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 /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /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"
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 xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirror.netcologne.de/gentoo/ rsync://mirror.netcologne.de/gentoo/ http://mirror.qubenet.net/mirror/gentoo/ ftp://mirror.netcologne.de/gentoo/ ftp://mirror.bytemark.co.uk/gentoo/ http://91.121.124.139/gentoo-distfiles/ http://ftp.snt.utwente.nl/pub/os/linux/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://mirror.bytemark.co.uk/gentoo/ rsync://rsync.europe.gentoo.org/gentoo-portage"
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/gamerlay /var/lib/layman/haskell /var/lib/layman/qt /var/lib/layman/sunrise /usr/local/portage"
SYNC="rsync://rsync11.de.gentoo.org/gentoo-portage"
USE="X a52 aac aalib acl acpi akode alsa amarok amd64 amr apache2 asf audiofile autotrace bash-completion berkdb blas blender-game blksha1 bluray branding btrfs bzip2 c++0x cairo cdda cdr chm clamav clamd clamdtop clang cli clucene colord corefonts cracklib crypt cryptsetup cscope css cups curl cxx d daap dbus declarative device-mapper dia djvu doc doomsday downloads-monitor dri drm dts dv dvd dvdnav dvdr ebook eds egl embedded emboss encode equalizer evo examples exif fam fastcgi fasttrack fbcondecor ffmpeg fftw firefox flac fluidsynth fontconfig fortran fts3 gbm gd gdbm geoip gif gimp gimpprint git gles gles1 gles2 glitz gnome gnome-keyring gnome-online-accounts gnuplot gnutella gnutls gold gpg gphoto2 gpm graphics graphite graphviz gstreamer gtk h323 haskell hddtemp hdri highlight hoogle hpcups hpijs hscolour ibus iconv icu ieee1394 imagemagick imap inkjar innodb inotify insecure-savers int64 introspection ipod ipv6 jabber jack java jpeg kde kdehiddenvisibility kipi kpathsea lapack lastfm lastfmradio latex lcms ldap libcaca libnotify libsamplerate libsecret live llvm-shared-libs lm_sensors loop-aes lxc lzma mad magic maildir map math mathml matplotlib matroska mbrola mdnsresponder-compat midi mikmod mjpeg mkl mmap mmx mmxext mng mod modules mono mp3 mp3tunes mp4 mpeg mudflap multilib musicbrainz mysql nautilus ncurses network networkmanager new-login nls npp nptl nsplugin nss octave odbc offensive ogg ogg123 openal opencl opencv opengl openmp openntpd opus oscar otr pam pango patented pcre pdf plasma plotutils png policykit postgres ppds prediction procmail pstricks publishers pulseaudio qt3support qt4 rar readline real rss ruby sasl sbcl scanner science sdl semantic-desktop sensord server session silc sipim smp sna snmp socialweb sound spamassassin spell sql sqlite sse sse2 ssl ssse3 startup-notification stream subversion svg systemd tcl tcmalloc tcpd tex4ht theora threads threadsafe thumbnail tiff tk truetype udev udisks unicode upcall upower urandom usb utempter v4l vaapi vda vdpau vhosts video vim vim-syntax vim-with-x visualization vlc vnc vorbis wayland wayland-compositor webdav webkit webp wifi wma wmf wmp wxwidgets x264 xanim xattr xcb xcomposite xetex xforms xine xml xorg xrandr xscreensaver xv xvid xwayland youtube zeitgeist 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="actions alias auth_basic auth_digest authn_anon authn_dbd 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 dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so 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" 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="de en fr fi" 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 i965" 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
Comment 4 Jonas Maaskola 2014-06-02 20:52:56 UTC
Unsurprisingly, the same issue exists with net-libs/webkit-gtk-2.4.3-r200

I.e. building of net-libs/webkit-gtk-2.4.3-r200 fails with the same symbol not being found during linking when gcc 4.7.3 is used. Again, using gcc 4.8.2, building is successful.
Comment 5 Rafał Mużyło 2014-06-03 02:27:04 UTC
This looks bogus to me.

Granted, I do have gcc 4.8 installed, but active is still 4.7.

The example from the debian bug builds just fine with gcc 4.7.
That bug references a different one, that talks about '--enable-libstdcxx-time', which has been used by Gentoo for close to 1.5 year.

libwebkitgtk-3.0.so has no undefined symbols in 'ldd -r' output either.
Comment 6 Jonas Maaskola 2014-06-03 12:33:13 UTC
(In reply to Rafał Mużyło from comment #5)

Rafał, thanks for looking into this.

OK, so I investigated a bit more. The bottom line is that the issue likely stems from having a system with some libraries built with gcc 4.7, some with gcc 4.8.


Here is what happens when I compile the code from the bug in the debian list, using gcc-4.7.3 (from portage), gcc-4.8.2 (from portage), or gcc-4.9-0 (built manually).

maaskola@localhost /tmp $ cat main.cc 
#include <chrono>
#include <iostream>

int main() {
  auto start = std::chrono::steady_clock::now();
  std::cout << "Hello World\n";
  auto end = std::chrono::steady_clock::now();
  std::cout << "Printing took "
    // duration_cast is required to avoid accidentally losing precision.
    << std::chrono::duration_cast<std::chrono::microseconds>(end - start).count()
    << "us.\n";
}
maaskola@localhost /tmp $ gcc --version
gcc (GCC) 4.9.0
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

maaskola@localhost /tmp $ g++ -std=gnu++11 main.cc -o main-v4.9 -Wall
maaskola@localhost /tmp $ ./main-v4.9 
Hello World
Printing took 101us.
maaskola@localhost /tmp $ g++-4.8.2 -std=gnu++11 main.cc -o main-v4.8 -Wall
maaskola@localhost /tmp $ ./main-v4.8 
Hello World
Printing took 72us.
maaskola@localhost /tmp $ g++-4.7.3 -std=gnu++11 main.cc -o main-v4.7 -Wall
maaskola@localhost /tmp $ ./main-v4.7 
./main-v4.7: relocation error: ./main-v4.7: symbol _ZNSt6chrono12steady_clock3nowEv, version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time reference

This was all using the libstc++.so from 4.9:

maaskola@localhost /tmp $ ldd main-v4.*
main-v4.7:
        linux-vdso.so.1 (0x00007fff1356d000)
        libstdc++.so.6 => /home/maaskola/local/gcc/4.9.0/lib64/libstdc++.so.6 (0x00007fa79a32a000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa79a035000)
        libgcc_s.so.1 => /home/maaskola/local/gcc/4.9.0/lib64/libgcc_s.so.1 (0x00007fa799e1e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa799a74000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa79a63a000)
main-v4.8:
        linux-vdso.so.1 (0x00007fff305ff000)
        libstdc++.so.6 => /home/maaskola/local/gcc/4.9.0/lib64/libstdc++.so.6 (0x00007fb36baca000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fb36b7d5000)
        libgcc_s.so.1 => /home/maaskola/local/gcc/4.9.0/lib64/libgcc_s.so.1 (0x00007fb36b5be000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb36b214000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb36bdda000)
main-v4.9:
        linux-vdso.so.1 (0x00007fff433ff000)
        libstdc++.so.6 => /home/maaskola/local/gcc/4.9.0/lib64/libstdc++.so.6 (0x00007f2c74985000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f2c74690000)
        libgcc_s.so.1 => /home/maaskola/local/gcc/4.9.0/lib64/libgcc_s.so.1 (0x00007f2c74479000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f2c740cf000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2c74c95000)

Switching to libstdc++ from 4.8 yields the same observations:

maaskola@localhost /tmp $ export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/:$LD_LIBRARY_PATH
maaskola@localhost /tmp $ ldd main-v4.*
main-v4.7:
        linux-vdso.so.1 (0x00007fffc23ff000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libstdc++.so.6 (0x00007f71c9520000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f71c922b000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f71c9015000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f71c8c6b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f71c9829000)
main-v4.8:
        linux-vdso.so.1 (0x00007fffaf7ff000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libstdc++.so.6 (0x00007fe19473b000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe194446000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007fe194230000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe193e86000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe194a44000)
main-v4.9:
        linux-vdso.so.1 (0x00007fff88fff000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libstdc++.so.6 (0x00007f5fc2866000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5fc2571000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1 (0x00007f5fc235b000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5fc1fb1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5fc2b6f000)
maaskola@localhost /tmp $ ./main-v4.9 
Hello World
Printing took 103us.
maaskola@localhost /tmp $ ./main-v4.8
Hello World
Printing took 71us.
maaskola@localhost /tmp $ ./main-v4.7 
./main-v4.7: relocation error: ./main-v4.7: symbol _ZNSt6chrono12steady_clock3nowEv, version GLIBCXX_3.4.17 not defined in file libstdc++.so.6 with link time reference

And, with libstdc++ from 4.7, we get the inverse observation:

maaskola@localhost /tmp $ export LD_LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/:$LD_LIBRARY_PATH
maaskola@localhost /tmp $ ldd main-v4.*
main-v4.7:
        linux-vdso.so.1 (0x00007fffffbff000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007f7e96638000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f7e96343000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007f7e9612d000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f7e95d83000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7e96940000)
main-v4.8:
./main-v4.8: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./main-v4.8)
        linux-vdso.so.1 (0x00007fffeb3f0000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007f45db8de000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f45db5e9000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007f45db3d3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f45db029000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f45dbbe6000)
main-v4.9:
./main-v4.9: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./main-v4.9)
        linux-vdso.so.1 (0x00007fff4a4c5000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007fda0c123000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fda0be2e000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgcc_s.so.1 (0x00007fda0bc18000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fda0b86e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fda0c42b000)
maaskola@localhost /tmp $ ./main-v4.9 
./main-v4.9: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./main-v4.9)
maaskola@localhost /tmp $ ./main-v4.8
./main-v4.8: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6: version `GLIBCXX_3.4.19' not found (required by ./main-v4.8)
maaskola@localhost /tmp $ ./main-v4.7 
Hello World
Printing took 90us.


So, apparently, libstdc++ of 4.8 and 4.9 are compatible w.r.t. steady_clock::now(), but incompatible with libstdc++ of 4.7.
When gcc 4.7 is used with libstdc++ of 4.8 or 4.9 or when gcc 4.8 or 4.9 are used with libstdc++ of 4.7 then the symbol is not found.



Perhaps, then, the linking issues I get when emerging webkit-gtk with gcc-4.7.3 are due some linked-to libraries already pulling in libstdc++ from 4.8.2?


I wrote a small script to check the libraries mentioned in the step during which the linking error happens when emerging webkit-gtk, and, indeed, found some that link to libstdc++ from 4.8.2 when I'm using the gcc-profile of 4.7.3.

Therefore, it is likely that the emerge failure of webkit-gtk that I reported is indeed bogus, as Rafał said.
Likely, emerging webkit-gtk should succeed on a system on which all libraries are built with either gcc 4.7 or 4.8, but not on systems with a mix.

As written initially, emerging webkit-gtk succeeds for me when I switch my gcc-profile to 4.8.2, so for me the issue is "solved".

Might it make sense for me to re-emerge @world with one version of gcc to avoid such issues in the future? At this point, should I prefer 4.7 or 4.8?
Or could this entire business be avoided simply by setting LD_LIBRARY_PATH? (I notice that it's un-set for the root-user)

Apologies, if these issues afterall are just due to the configuration of my system!
Comment 7 Rafał Mużyło 2014-06-03 16:29:21 UTC
First of all, LD_LIBRARY_PATH is unset, as libtool doesn't like it set, does many bad thing, including (IIRC) adding RPATH to libs.

main-v4.7:
        linux-vdso.so.1 (0x00007fff1356d000)
        libstdc++.so.6 => /home/maaskola/local/gcc/4.9.0/lib64/libstdc++.so.6 (0x00007fa79a32a000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa79a035000)
        libgcc_s.so.1 => /home/maaskola/local/gcc/4.9.0/lib64/libgcc_s.so.1 (0x00007fa799e1e000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa799a74000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa79a63a000)

This should offer you a strong hint what you've did wrong - gcc isn't a simple package to build, perhaps not as complicated as firefox/webkit-gtk, but there are pitfalls/gotchas abound. Consider yourself fallen into one.

This is (in a way) alike to "I've installed nvidia-drivers outside of portage". For C programs, it doesn't really matter (AFAIK), but C+ programs are a bit more tricky. Those "`GLIBCXX_3.4.19' not found" errors are actually the expected result of libstdc++ downgrade.
Comment 8 Jonas Maaskola 2014-06-03 20:25:02 UTC
(In reply to Rafał Mużyło from comment #7)
> First of all, LD_LIBRARY_PATH is unset, as libtool doesn't like it set, does
> many bad thing, including (IIRC) adding RPATH to libs.
> 
> main-v4.7:
>         linux-vdso.so.1 (0x00007fff1356d000)
>         libstdc++.so.6 =>
> /home/maaskola/local/gcc/4.9.0/lib64/libstdc++.so.6 (0x00007fa79a32a000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007fa79a035000)
>         libgcc_s.so.1 => /home/maaskola/local/gcc/4.9.0/lib64/libgcc_s.so.1
> (0x00007fa799e1e000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fa799a74000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fa79a63a000)
> 
> This should offer you a strong hint what you've did wrong - gcc isn't a
> simple package to build, perhaps not as complicated as firefox/webkit-gtk,
> but there are pitfalls/gotchas abound. Consider yourself fallen into one.
> 
> This is (in a way) alike to "I've installed nvidia-drivers outside of
> portage". For C programs, it doesn't really matter (AFAIK), but C+ programs
> are a bit more tricky. Those "`GLIBCXX_3.4.19' not found" errors are
> actually the expected result of libstdc++ downgrade.


(Just to explain: the gcc 4.9 build is in my home dir as I use that for c++ development; it's not used for any gentoo portage building...; just thought I might include it in the analysis of that example code from the debian list - which was done as my user as visible from the prompt)

OK, so thanks! I guess I'll then migrate to using gcc 4.8 profile henceforth.

As, already initially written, this way my webkit-gtk build succeeded, and my bug report is moot.

I'll close it as resolved. Thanks again for holding my hand :)
Comment 9 Pacho Ramos gentoo-dev 2014-07-21 12:49:32 UTC

*** This bug has been marked as a duplicate of bug 513386 ***