Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 297685 - sys-devel/gcc-config: LDPATH of current gcc version appears before newest available
Summary: sys-devel/gcc-config: LDPATH of current gcc version appears before newest ava...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 330067 340517 355419 372271 398349 402169 437100 (view as bug list)
Depends on: 168884
Blocks:
  Show dependency tree
 
Reported: 2009-12-20 19:28 UTC by Scott 'me22' McMurray
Modified: 2023-02-07 20:11 UTC (History)
11 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott 'me22' McMurray 2009-12-20 19:28:53 UTC
To experiment with C++0x features, I have gcc-4.4.2 installed (among others -- I'm using multislot), but leave my gcc-config set to stable (4.3.4) for normal building.

Somehow, though, the order in which I installed gave this ordering:

/etc/env.d $ grep LDPATH *
05gcc-x86_64-pc-linux-gnu:LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/32"

The result of which is that when I tried to compile, it linked the wrong library:

$ g++-4.4.2 -std=gnu++0x test.cc && ./a.out
./a.out: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./a.out)

Sorting the entries as follows and running env-update made it work.

$ grep 4.4 *
05gcc-x86_64-pc-linux-gnu:LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.1/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/32:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6:/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/32"

But now I'm wondering whether that means that my normal compiles in emerge will pick the 4.4 version of libstdc++ instead of the stable one.

Reproducible: Didn't try

Steps to Reproduce:




Portage 2.1.6.13 (default/linux/amd64/10.0/desktop, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.30-gentoo-r5 x86_64)
=================================================================
System uname: Linux-2.6.30-gentoo-r5-x86_64-Intel-R-_Core-TM-2_CPU_6420_@_2.13GHz-with-gentoo-1.12.13
Timestamp of tree: Sat, 19 Dec 2009 19:30:01 +0000
app-shells/bash:     4.0_p35
dev-java/java-config: 2.1.9-r1
dev-lang/python:     2.6.4
dev-python/pycrypto: 2.1.0_beta1
dev-util/cmake:      2.6.4-r3
sys-apps/baselayout: 1.12.13
sys-apps/sandbox:    1.6-r2
sys-devel/autoconf:  2.13, 2.63-r1
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2
sys-devel/binutils:  2.18-r3
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.6b
virtual/os-headers:  2.6.27-r2
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=core2 -O2 -O3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /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 /etc/udev/rules.d"
CXXFLAGS="-march=core2 -O2 -O3 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--jobs=3 --load-average=3"
FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch"
GENTOO_MIRRORS="http://gentoo-distfiles.mirrors.tds.net"
LANG="en_CA.UTF-8"
LDFLAGS="-Wl,-O1"
LINGUAS="en en_CA en_GB fr"
MAKEOPTS="-j3 --jobs=4 --load-average=4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage/layman/zugaina /usr/local/portage/layman/tante /usr/local/portage/layman/games /usr/local/portage/layman/lila-theme /usr/local/fonts-overlay /usr/local/misc-overlay /usr/local/nvidia-overlay /usr/local/themes-overlay /usr/local/lang-overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X a52 aac aalib acl acpi alsa amd64 audacious avahi bash-completion bidi branding bzip2 cairo cdaudio cdda cddb cdparanoia cdr cjk cli consolekit cracklib crypt css cups curl cxx dbus dga directfb dri dts dvd dvdr dvi emboss encode exif fam fastcgi fbcon ffmpeg fftw firefox flac ftp fuse gif gimp git glade glut gmp gnome gnome-keyring gphoto2 gpm graphviz gstreamer gtk gtkhtml gtkspell hal iconv icq icu idn ieee1394 imlib ipv6 jabber java5 jpeg jpeg2k latex ldap libnotify libsamplerate libwww lirc lm_sensors mad matroska memlimit midi mikmod mmap mmx mng modules mp3 mp4 mpeg mplayer msn mudflap multilib musepack mysql nat nautilus ncurses network nls nptl nptlonly ntfs nvidia offensive ogg openal opengl openmp oscar pam pch pcre pdf perl png posix ppds pulseaudio python qt3support rar rdesktop readline recode samba schroedinger sdl session sockets spell sse sse2 ssl startup-notification subversion svg sysfs tcpd threads thunar tiff truetype unicode usb valgrind vcd vnc vorbis wxwidgets x264 xcb xchatdccserver xcomposite xine xinerama xml xorg xosd xscreensaver xulrunner xv xvid zlib" 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" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="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 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en en_CA en_GB fr" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nv nvidia"
Unset:  CPPFLAGS, CTARGET, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Rafał Mużyło 2009-12-21 14:13:57 UTC
Most prbably, they will pick up the new version now.
There are other gcc env variables, that could help you.
Comment 2 SpanKY gentoo-dev 2009-12-29 07:16:15 UTC
i fixed this mostly in the past (cant find the bug), but guess i missed a spot
Comment 3 Scott 'me22' McMurray 2009-12-29 18:20:20 UTC
(In reply to comment #2)
> i fixed this mostly in the past (cant find the bug), but guess i missed a spot
> 

I'm not entirely certain that the active one being first is the bug -- it might be necessary for the not-explicitly-versioned gcc binary to get the correct library version.

It's possible that what I really want is for the g++-4.4.2 binary to know to use a specific directory, rather than look at the LDPATH.

Thanks for looking into it.
Comment 4 SpanKY gentoo-dev 2010-07-27 18:24:37 UTC
*** Bug 330067 has been marked as a duplicate of this bug. ***
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2010-10-17 11:38:26 UTC
*** Bug 340517 has been marked as a duplicate of this bug. ***
Comment 6 SpanKY gentoo-dev 2011-02-22 06:36:06 UTC
*** Bug 355419 has been marked as a duplicate of this bug. ***
Comment 7 Ryan Hill (RETIRED) gentoo-dev 2011-10-13 05:15:34 UTC
Mike, do you have any ideas on how to fix this?
Comment 8 SpanKY gentoo-dev 2012-01-10 20:50:16 UTC
*** Bug 398349 has been marked as a duplicate of this bug. ***
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2012-02-04 15:39:05 UTC
*** Bug 402169 has been marked as a duplicate of this bug. ***
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-02-08 10:08:16 UTC
We should really focus on this one because it is almost a blocker for almost any, non-statically linked C++ programs in Gentoo. Users don't really like when a lot of stuff stops working because they switched gcc version like we allowed them to.

And the number of C++ components in system is growing. There's no point in pretending C++ does not exist and pointing users to ugly solutions like gobject or vala.

eix is the most common Gentoo tool requiring C++. The gold linker makes it useless to switch gcc at the moment because you won't be able to link compiled executables anymore. And some of the mesa drivers require LLVM which gets broken by gcc switch too.
Comment 11 Ryan Hill (RETIRED) gentoo-dev 2012-02-26 05:11:30 UTC
Is there a way to force the compiler to use the libraries that correspond with its version rather than rely on LDPATH?  Then we could just sort LDPATH in descending order to keep runtime from breaking while preventing new builds with older GCCs linking against newer libraries,
Comment 12 SpanKY gentoo-dev 2012-02-29 20:14:42 UTC
(In reply to comment #10)

random C++ rants don't belong here.  we couldn't care less.

(In reply to comment #11)

during the linking process, gcc itself takes care of making sure the right libs are linked against (via -L to its internal paths) so the symbol versioning and such should do the right thing.  however, it doesn't implicitly include -rpath flags, so the runtime linker (ldso) will use the ld.so.conf search paths.  by & large this should be correct because shared libraries are *supposed* to be backwards compatible (hence they have the same SONAME).

the only way around this is to use -rpath to gcc's internal libraries, and that's a lot worse general solution.

i've changed gcc-config-1.5.1 to not prefer active profile's ldpath over all others.  the downside to this is if you are keeping your active gcc tied to the stable (such as 4.5.x) but install a newer one for playing around (such as 4.6.x or 4.7.x), the runtime shared libraries will come from those (possibly unstable) versions.  people can't have it both ways.
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2012-02-29 21:18:37 UTC Comment hidden (obsolete)
Comment 14 Ryan Hill (RETIRED) gentoo-dev 2012-03-01 04:12:59 UTC
As long as you can set your gcc to a stable version, rebuild world, and then uninstall the unstable version without breaking anything I'm happy.  Thanks for taking care of it.
Comment 15 SpanKY gentoo-dev 2012-03-02 05:57:51 UTC Comment hidden (obsolete)
Comment 16 SpanKY gentoo-dev 2012-03-04 18:36:56 UTC
*** Bug 372271 has been marked as a duplicate of this bug. ***
Comment 17 SpanKY gentoo-dev 2012-10-04 03:54:55 UTC
*** Bug 437100 has been marked as a duplicate of this bug. ***