Bug 166870
| Summary: | ld reports "cannot find -lstdc++_shared" after upgrade to gcc-3.4.4-2.fc3 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Dirkse <sdirkse> | ||||
| Component: | binutils | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 3 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2005-08-27 15:25:05 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
That is an Intel compiler bug though.
If the linker has been able to find
/usr/lib/gcc/x86_64-*/*/libstdc++.so, it should be able to find
libstdc++_shared.so and libstdc++_nonshared.a in the same directory as well.
From the above command line, it seems that -L/usr/lib/gcc/x86_64-*linux/3.4.*/
is not passed to the linker. So my guess is that Intel compiler has
a symlink from probably /opt/intel_cce_80/lib/libstdc++.so to
/usr/lib/gcc/x86_64-*linux/3.4.*/libstdc++.so. But that's just wrong.
Either they should point that symlink to /usr/lib/libstdc++.so.6 directly
(and live with not being able to link programs that create classes that inherit
from basic_stringbuf), or better they should instead of creating symlinks
pass -L`gcc -print-search-dirs| sed -n '/^libraries/{s,^libraries:
=,,;s,:.*$,,;p}'`
As a workaround, you can pass -L /usr/lib/gcc/x86_64-redhat-linux/3.4.4/
on the link command line.
In any case, you should report this to Intel, not here.
Created attachment 118187 [details]
Example for ld bug - unzip and run ./all.sh
Jakob, You're skeptical - I can respect that. But you skipped over this one a bit too quickly. The linker does find /usr/lib/gcc/x86_64-*/*/libstdc++.so, and it *should* be able to find libstdc++_shared.so and libstdc++_nonshared.a in the same directory, *but it does not*. That's the bug. If you look at the ld command sent in the original report, you'll see that - L/usr/lib/gcc/x86_64-redhat-linux/3.4.4/ is included, so adding it again won't help as a workaround. I've added a zip file to this bug that reproduces the problem without using any Intel compiler tools. To run it, just unzip and do ./all.sh. This creates a .o file using g++ and then uses ld in two ways to create the executable. If you diff works.sh and fails.sh (the scripts that run ld) you'll see the difference between success and failure is very small. That is still a bug in Intel compiler driver resp. in the way you are invoking the linker if you are invoking it by hand. When linking a dynamically linked program (as in this case), you can't ever have -Bstatic mode at the end of the command line. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050603 Fedora/1.7.8-1.2.1.legacy Description of problem: I was using the 64-bit Intel 8.1 compilers for quite some time on this machine to build hello.cpp (and other stuff :-) but that broke when I installed the updated gcc with the new libraries. The command "icpc -v -o hello hello.cpp" spits out a long ld command: ld /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/3.4.4/crtbegin.o --eh-frame-hdr -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /tmp/icpcmQ91zp.o -Qy -L/opt/intel_cce_80/lib -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4/ -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64 -Bstatic -lsvml -limf -Bdynamic -lm -Bdynamic -lstdc++ -Bstatic -lirc -Bdynamic -lgcc_s -lgcc -Bdynamic -lcxaguard -lc -lgcc_s -lgcc -Bstatic -lirc_s /usr/lib/gcc/x86_64-redhat-linux/3.4.4/crtend.o /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crtn.o ld: cannot find -lstdc++_shared If I hack the file /usr/lib/gcc/x86_64-redhat-linux/3.4.3/libstdc++.so like this: /* GNU ld script * hacked by SPD on 26 Aug 2005, * otherwise it was breaking intel's icpc * the (uncommented) GROUP line below is the original content */ /* GROUP ( -lstdc++_nonshared -lstdc++_shared ) */ INPUT ( /usr/lib64/libstdc++.so.6 ) then it works OK. Version-Release number of selected component (if applicable): binutils-2.15.92.0.2-5.1 gcc-c++-3.4.4-2.fc3 How reproducible: Always Steps to Reproduce: 1. Have Intel's compiler installed (if that's impossible, I can try sending a .o file to see if that take's icpc out of the picture). 2. run "icpc -o hello hello.cpp" on the canonical "Hello, world!" program for C++ 3. Actual Results: r.gams.com:/home/distrib/lang/cpp$cat hello.cpp #include <iostream> int main (int argc, char **argv) { std::cout << "Hello, world!\n"; return 0; } /* main */ r.gams.com:/home/distrib/lang/cpp$icpc -v -o hello hello.cpp Version 8.1 /opt/intel_cce_80/bin/mcpcom -_g -mP3OPT_inline_alloca -D__HONOR_STD -D__ICC=810 -D__INTEL_COMPILER=810 -D__INTEL_COMPILER_BUILD_DATE=20050406 "-_Asystem(unix)" -D__ELF __ "-_Acpu(x86_64)" "-_Amachine(x86_64)" -D__PTRDIFF_TYPE__=long "-D__SIZE_TYPE__=unsigned long" -D__WCHAR_TYPE__=int "-D__WINT_TYPE__=unsigned int" -D__OPTIMIZE__ -D__NO_ MATH_INLINES -D__NO_STRING_INLINES -D__GNUC__=3 -D__GNUC_MINOR__=4 -D__GNUC_PATCHLEVEL__=4 -D__NO_INLINE__ -D__LP64__ -D_LP64 -D__pentium4 -D__pentium4__ -D__SSE2__ -D__MM X__ -D__SSE__ -D__tune_pentium4__ -D__extension__= -D_GNU_SOURCE=1 -D__GNUG__=3 -D__DEPRECATED=1 -D__GXX_WEAK__=1 -D__GXX_ABI_VERSION=102 -D__USER_LABEL_PREFIX__= -D__REGI STER_PREFIX__= -D__INTEL_RTTI__ -D__EXCEPTIONS=1 -D__unix__ -D__unix -D__linux__ -D__linux -D__gnu_linux__ -B -Dunix -Dlinux -D__x86_64 -D__x86_64__ -_8 -_l -_b -_W5 -p -- bool -tused -mGLOB_eh_linux -x --mspp --gnu_version=344 --bool -mP1OPT_version=810 -mP1OPT_print_version=FALSE -mP3OPT_use_mspp_call_convention -mCG_use_gas_got_workaround =F -mP2OPT_align_option_used=TRUE "-mGLOB_options_string=-v -o hello" -mGLOB_cxx_limited_range=FALSE -mGLOB_as_output_backup_file_name=/tmp/icpcoREm5das_ -mP3OPT_honor_flo at_conversion=1 -mP3OPT_honor_double_conversion=1 -mGLOB_lp64 -mGLOB_machine_model=GLOB_MACHINE_MODEL_EFI2 -mIPOPT_args_in_regs=0 -mP2OPT_pgo_value_profile_use=T -mP2OPT_i l0_eho -mIPOPT_obj_output_file_name=/tmp/icpcZa0JSr.o -mP3OPT_asm_target=P3OPT_ASM_TARGET_GAS -mGLOB_obj_output_file=/tmp/icpcZa0JSr.o -mP1OPT_source_file_name=hello.cpp h ello.cpp /opt/intel_cce_80/substitute_headers/c++ /usr/include/c++/3.4.4 /usr/include/c++/3.4.4/x86_64-redhat-linux /usr/include/c++/3.4.4/backward /opt/intel_cce_80/include /opt/intel_cce_80/substitute_headers /usr/lib/gcc/x86_64-redhat-linux/3.4.4/include /usr/include ld /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/3.4. 4/crtbegin.o --eh-frame-hdr -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /tmp/icpcZa0JSr.o -Qy -L/opt/intel_cce_80/lib -L/usr/lib/gcc/x86_64-redhat-linux/3.4.4/ -L /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64 -Bstatic -lsvml -limf -Bdynamic -lm -Bdynamic -lstdc++ -Bstatic -lirc -Bdynamic -lgcc_s -lgcc -Bdynamic -lcxaguard -lc -lgcc_s -lgcc -Bstatic -lirc_s /usr/lib/gcc/x86_64-redhat-linux/3.4.4/crtend.o /usr/lib/gcc/x86_64-redhat-linux/3.4.4/../../../../lib64/crtn.o ld: cannot find -lstdc++_shared rm /tmp/icpcUu2XYPgas rm /tmp/icpcoREm5das_ rm /tmp/icpcZVtrcCarg rm /tmp/icpcZa0JSr.o r.gams.com:/home/distrib/lang/cpp$ Expected Results: I should have gotten an executable Additional info: The fact that this happened after updating gcc (and I think binutils with that, /usr/bin/ld is dated 29 June 2005), and that hacking the GNU ld script as mentioned above, points the finger at ld or gcc's libs setup or a combination of the two.