Bug 166870 - ld reports "cannot find -lstdc++_shared" after upgrade to gcc-3.4.4-2.fc3
ld reports "cannot find -lstdc++_shared" after upgrade to gcc-3.4.4-2.fc3
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-26 12:31 EDT by Steve Dirkse
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-27 11:25:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example for ld bug - unzip and run ./all.sh (2.45 KB, application/octet-stream)
2005-08-27 09:28 EDT, Steve Dirkse
no flags Details

  None (edit)
Description Steve Dirkse 2005-08-26 12:31:14 EDT
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.
Comment 1 Jakub Jelinek 2005-08-26 13:14:39 EDT
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.
Comment 2 Steve Dirkse 2005-08-27 09:28:52 EDT
Created attachment 118187 [details]
Example for ld bug - unzip and run ./all.sh
Comment 3 Steve Dirkse 2005-08-27 09:35:16 EDT
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.
Comment 4 Jakub Jelinek 2005-08-27 11:25:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.