I upgraded to gcc-4.7.1 and now skype says "/opt/bin/skype: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory". I am on amd64, and a locate libstdc++.so.6 says: /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/libstdc++.so.6 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/libstdc++.so.6.0.17 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6 /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6.0.17 /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/libstdc++.so.6.0.17-gdb.py /usr/share/gdb/auto-load/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6.0.17-gdb.py So it compiled the library, but it seems something got missed there and it can't find that 32 bit library. Reproducible: Always
However I can run it if I do: LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/32" /opt/bin/skype But shouldn't something like that be done automatically?
(In reply to comment #1) > However I can run it if I do: > LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.1/ > 32" /opt/bin/skype > But shouldn't something like that be done automatically? Yes, $ grep -r gcc.*32 /etc/ld.so.conf* /etc/env.d/* /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32 /etc/env.d/gcc/x86_64-pc-linux-gnu-4.7.1:LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32" # env-update # source /etc/profile Are you saying you don't have the env.d file in place, or... ?
Also missing attachement of 'emerge --info'. Can't reassign the bug anywhere before that.
Don't know why, but I seem to miss that file: Darkness stormbyte # env-update >>> Regenerating /etc/ld.so.cache... Darkness stormbyte # source /etc/profile Darkness stormbyte # exit exit stormbyte@Darkness ~ $ skype skype: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory stormbyte@Darkness ~ $ grep -r gcc.*32 /etc/ld.so.conf* /etc/env.d/* (nothing outputted)
Created attachment 317029 [details] emerge --info emerge --info output
Also, before this bug is closed due to test of LTO (which I don't think is related). I attach a list of package.env disabling LTO: cat /etc/portage/package.env | grep nolto.conf www-client/firefox notmpfs.conf nolto.conf sys-process/numactl nolto.conf sys-apps/pciutils nolto.conf sys-apps/sysvinit nolto.conf dev-lang/perl nolto.conf dev-lang/python nolto.conf app-cdr/cdrtools nolto.conf media-libs/alsa-lib nolto.conf dev-libs/elfutils nolto.conf dev-util/dialog nolto.conf sys-devel/llvm nolto.conf sys-fs/ntfs3g nolto.conf x11-libs/qt-script nolto.conf media-libs/mesa nolto.conf dev-libs/gobject-introspection nolto.conf sys-libs/gpm nolto.conf sys-devel/gcc nolto.conf sys-devel/gcc nolto.conf sys-apps/sandbox nolto.conf sys-fs/e2fsprogs nolto.conf dev-lang/spidermonkey nolto.conf dev-libs/boost nolto.conf dev-lang/ruby nolto.conf dev-util/valgrind nolto.conf x11-libs/qt-webkit nolto.conf x11-libs/wxGTK nolto.conf media-gfx/imagemagick nolto.conf app-emulation/virtualbox nolto.conf media-video/ffmpeg nolto.conf www-client/chromium notmpfs.conf nolto.conf media-video/mplayer nolto.conf media-video/mkvtoolnix nolto.conf x11-base/xorg-server nolto.conf app-cdr/cdrdao nolto.conf media-libs/libdc1394 nolto.conf dev-db/mysql nolto.conf x11-libs/qt-declarative nolto.conf app-emulation/wine nolto.conf kde-base/kdelibs nolto.conf kde-base/plasma-workspace nolto.conf sys-boot/grub nolto.conf dev-libs/glib nolto.conf sys-auth/polkit nolto.conf lxde-base/lxpanel nolto.conf app-text/rarian nolto.conf dev-libs/libburn nolto.conf app-admin/gkrellm nolto.conf dev-python/notify-python nolto.conf sys-apps/hdparm nolto.conf www-plugins/lightspark nolto.conf
More info: cat /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1 cat /etc/env.d/gcc/x86_64-pc-linux-gnu-4.7.1 LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1" MANPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/man" INFOPATH="/usr/share/gcc-data/x86_64-pc-linux-gnu/4.7.1/info" STDCXX_INCDIR="g++-v4" GCC_PATH="/usr/x86_64-pc-linux-gnu/gcc-bin/4.7.1" So I seem to have only 64bit environment for that libraries.
your /etc/env.d/gcc/x86_64-pc-linux-gnu-4.7.1 is broken. it should read: LDPATH="/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32" post the full build log of gcc as an attachment
I solved it and found the posible cause. I had X32 support enabled in kernel. That was the two changes I made when this bug happened (X32 and update GCC to 4.7.1), but I did not change my cflags to use X32, nor my CHOST (as can be seen in emerge --info) so I thought it would not apply. So you are free to decide wether this is invalid, or whether GCC should do more checks before enabling X32 support, or to tell me that is not the cause. Do you still need the output of GCC's build log?
I am promoting this to test-request, since I think enabling X32 binaries in kernel have this undesired side effect. I am not changing arch to X32, just let it to have that option, so gcc should be compiled as always IMHO.
Reopened
