Summary: | dev-lang/icc-10.X and dev-lang/ifc-10.X problems with libstdc++.so.5 after sys-libs/libstdc++-v3-3.3.6 recompile | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diogo Tridapalli <diogot> |
Component: | [OLD] Library | Assignee: | Sébastien Fabbro (RETIRED) <bicatali> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | alexxy, axiator, bugzilla-gentoo, deduktionstheorem, phmagic, realnc, rsa4046, schiotz, sci, t4bs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
same problem here as OP (ifc only; icc not installed), emerge --info and revdep-rebuild attached
same result as previous poster |
Description
Diogo Tridapalli
2009-02-17 20:12:58 UTC
Created attachment 182370 [details]
same problem here as OP (ifc only; icc not installed), emerge --info and revdep-rebuild attached
Same here on AMD64. /opt/intel/cce/10.1.018/bin/mcpcom: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/mcpcom) /opt/intel/cce/10.1.018/bin/tselect: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/tselect) /opt/intel/cce/10.1.018/bin/pronto_tool: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/pronto_tool) /opt/intel/cce/10.1.018/bin/prelink: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/prelink) /opt/intel/cce/10.1.018/bin/profrun.bin: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/profrun.bin) /opt/intel/cce/10.1.018/bin/codecov: /usr/lib32/libstdc++.so.5: no version information available (required by /opt/intel/cce/10.1.018/bin/codecov) As a workaround it is possible to use gcc:3.3 as provider for libstdc++-v3 and deinstall the (broken) lib. With gcc:3.3 it's just a few more files, compile time is quite similar i think. The workaround works here, thanks emerald, but the bug still not resolved ;-) *** Bug 262501 has been marked as a duplicate of this bug. *** If you have app-emulation/emul-linux-x86-compat installed, there is an easy workaround: Just delete the files /usr/lib32/libstdc++.so.5* icc/icpc/ifc will then use the similar (but working!) files from app-emulation/emul-linux-x86-compat, installed in /usr/lib32/libstdc++-v3/ /Jakob Jakob, thank you for your input, it works at mine. Jakob, Thanks! - your fix works for me as well. Cheers After removing libstdc++-v3, adding libstdc++-v3 to the package.provided file and reemerging icc, revdep-rebuild still reports libomp_db.so as broken: broken /opt/intel/cce/10.0.026/lib/libomp_db.so (requires libstdc++.so.5) Any ideas? Do you have app-emulation/emul-linux-x86-compat installed? You should have the file /usr/lib32/libstdc++-v3/libstdc++.so.5 Probably you also need to run update-env to update the cache. /Jakob I do have emul-linux-x86-compat installed and the library is in place. Unfortunately update-env didn't help. ldd reports the following. # ldd -v /opt/intel/cce/10.0.026/lib/libomp_db.so linux-vdso.so.1 => (0x00007fff9b3ff000) libm.so.6 => /lib/libm.so.6 (0x00007f0f92f6a000) libstdc++.so.5 => not found libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f0f92d5b000) libc.so.6 => /lib/libc.so.6 (0x00007f0f92a13000) libdl.so.2 => /lib/libdl.so.2 (0x00007f0f9280f000) /lib64/ld-linux-x86-64.so.2 (0x00007f0f9332f000) Version information: /opt/intel/cce/10.0.026/lib/libomp_db.so: libgcc_s.so.1 (GCC_3.0) => /lib/libgcc_s.so.1 libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6 libstdc++.so.5 (GLIBCPP_3.2) => not found libstdc++.so.5 (CXXABI_1.2) => not found /lib/libm.so.6: libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6 /lib/libgcc_s.so.1: libc.so.6 (GLIBC_2.2.5) => /lib/libc.so.6 /lib/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 /lib/libdl.so.2: ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 libc.so.6 (GLIBC_PRIVATE) => /lib/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/libc.so. The problem is that now since I deinstalled libstdc++-v3, the 64-bit version /usr/lib64/libstdc++.so.5 is missing which is needed by libomp_db.so. Reinstalling libstdc++-v3 fixes this but brings us back to the "no version information available" issue. Do not uninstall anything, just delete the files /usr/lib32/libstdc++.so.5* Of course they will come back if the package is upgraded, but hopefully any upgrade fixes this bug anyway :-) /Jakob I don't know if this is related, I came here via bug #262501 (icc always gets rebuilt by revdep-rebuild). I also have the revdep-rebuild problem, but with dev-lang/icc-11.1.046-r3 (no 10.X) on ~amd64: > reconcilio -p # reconcilio is paludis' revdep-prebuild Searching for broken packages... Broken packages: * dev-lang/icc-11.1.046-r3:0::installed /opt/intel/Compiler/11.1/046/bin/intel64/iidb (requires libDebuggerData.so libDebuggerServices.so libPostOffice.so libScheduler.so libxerces-c.so.27) Building dependency list: ... 296 steps These packages will be installed: * dev-lang/icc::science [R 11.1.046-r3] <target> idb ipp mkl build_options: -optional_tests -trace Total: 1 package (1 rebuild) Checking for possible errors...... * No unread news items found Executing /opt/intel/Compiler/11.1/046/bin/intel64/prelink works. Created attachment 204197 [details]
same result as previous poster
Also on ~amd64, I now also have same result from dev-lang/icc-11.1.046-r3 as Stephan Friedrichs above (but not using paludis), revdep-rebuild always wants to rebuild icc
The problem seems to be gone on my boxes after updates to icc and ifc 11.1.056 and with a re-emerge of libstdc++-v3. Could someone confirm this? (In reply to comment #16) > The problem seems to be gone on my boxes after updates to icc and ifc 11.1.056 > and with a re-emerge of libstdc++-v3. Could someone confirm this? > I can confirm on my system that this bug is fixed with icc and ifc 11.1.056 (In reply to comment #16) > The problem seems to be gone on my boxes after updates to icc and ifc 11.1.056 > and with a re-emerge of libstdc++-v3. Could someone confirm this? > That doesn't fix the problem for me (on ~amd64). (In reply to comment #16) > The problem seems to be gone on my boxes after updates to icc and ifc 11.1.056 > and with a re-emerge of libstdc++-v3. Could someone confirm this? > Look to be gone here too! > (In reply to comment #16)
> > The problem seems to be gone on my boxes after updates to icc and ifc 11.1.056
> > and with a re-emerge of libstdc++-v3. Could someone confirm this?
> That doesn't fix the problem for me (on ~amd64).
It doesn't fix it for me either. I'm on amd64 (w/o ~, except for some packages like ifc,icc). When I use USE=idb and emerge ifc and icc, everything works. However, revdep-rebuild will remerge either ifc or icc (whichever I emerged first, and only once - it won't keep doing it every time I run revdep-rebuild) and this breaks things (many files disappear, e.g. causing ld not to find -limf).
The problem in my case seems to be the combination of ifc and icc, with the idb USE flag enabled. I actually have to *actively* disable it for icc (USE=-idb, I don't quite understand where the automatic support for idb comes from, it's not there for ifc). Anyway, ifc and icc seem to provide the same files in the same directories and that may well be the culprit here.
After USEing -idb for both icc and ifc (+idb *only* on icc gives the same problem),
# emerge -C ifc icc && emerge ifc icc
did the trick for me.
(In reply to comment #20) > However, revdep-rebuild will remerge either ifc or icc (whichever I emerged > first, and only once - it won't keep doing it every time I run revdep-rebuild) > and this breaks things (many files disappear, e.g. causing ld not to find > -limf). Yes, there are problems with the current 11.1.056 icc and idb ebuilds, such that re-emerging them will dismiss some required libraries (removing the rpm parts). The only way I found is to split the core common libraries for icc and ifc into new ebuilds. I'm trying to see with upstream if we are allowed to re-distribute the devlibs rpm at least. (In reply to comment #4) > The workaround works here, thanks emerald, but the bug still not resolved ;-) For the "/usr/lib32/libstdc++.so.5: no version information available" part of this bug please see bug 335733. (In reply to comment #21) There are also problems with the 11.1.072 icc and ifc ebuilds. (In reply to comment #23) > (In reply to comment #21) > > There are also problems with the 11.1.072 icc and ifc ebuilds. > comments like this doesn't help much. What is wrong and how could it be fixed? Please test new version in sci overlay (In reply to comment #25) > Please test new version in sci overlay Would it be possible to remove packages from the overlay that are already in portage? I added the overlay to test icc, but I'm getting a conflict with openmpi. Or is this intended somehow? No we can't. The versions in the overlay are the same version numbers, but the implementation in the ebuild differs. Shouldn't the changes be put in portage? Everything is new. Completely new scheme and an additional eclass. Lets test it a little and then it will be moved. Finally found some time to try this out. Unfortunately, emerging abort with a sandbox access violation: * Tagging intel-common ACCESS DENIED mkdir: /opt/intel mkdir: cannot create directory `/opt/intel': Permission denied VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: mkdir S: deny P: intel A: /opt/intel R: /opt/intel C: mkdir -p /opt/intel composerxe-2011.2.137/licenses Please at the complete build.log My fault, it is fixed now. Thanks. It emerged fine now. I've successfully built my projects with it, and everything runs fine. Some (probably naive) benchmarking reveals that this compiler is still ahead of GCC in producing faster binaries. Btw, there's now a newer version available (2011 update2). *** This bug has been marked as a duplicate of bug 304239 *** |