Link problem using gcc (C++) on Linux

running link using gcc-3.3.1 on Linux2.4.20-8 as seen on the next link line...
I get:

==> Loading raim ...
gcc RAIM_Start.o Cell.o CellInfo.o CellStateManager.o CellTimerManager.o DataDumpManager.o HandlerData.o ImminentAlarmCell.o StateCell.o HandlerMMI.o StrX.o HandlerSky.o ParseConstants.o ParseErrorHandler.o ParseHandler.o ParseTimer.o ParseUtil.o XMLAttribute.o XMLNode.o HandlerTest.o AdminHandler.o RAIM.o RAIM_Admin.o RAIM_Config.o RAIM_Ini.o Outage.o DateTime.o Position.o AbortDump.o CDC_RAIM_Summary.o UpdateBNSMsg.o TransitionToSingleMsg.o TransferDumpMsg.o SkyDumpRequest.o OutageRequestMsg.o OutageInfoMsg.o HeartBeatMessage.o ForecastMessage.o EndOfDump.o DumpRequestMsg.o DumpMessage.o FactoryTemplateRAIM.o CDC_MultiMessageFactory.o RAIM_Message.o MMI_ResponseMessage.o MMI_Message.o MMI_RequestMessage.o MMI_MessageFactory.o Pkg_X_RAIM.o x_raim.o Pkg_HandlerData.o Pkg_HandlerMMI.o Pkg_HandlerSky.o Pkg_HandlerTest.o Pkg_Admin.o Pkg_Msg_Raim.o Pkg_Messages.o Pkg_Factories.o Pkg_FIFO_Msg.o Pkg_RAIM_MMI_Msg.o Pkg_MMI_RAIM_Msg.o MainX_RAIM.o -L/sde/taaats_6/case/t_product/taaats/linux_i86/XERCES/xerces-c-obj_2_5_0-linux_i86/lib -lxerces-c -L/sde/taaats_6/case/t_product/taaats/linux_i86/GCC/gcc-3.3.1-i686-Linux2.4.20-8/lib -lstdc++ -L/home/dgogoasa/product/obj_i386-pc-linux2.4/common_cpp/ref/libCxx -lcommon_cpp -L/home/dgogoasa/product/obj_i386-pc-linux2.4/agp_lib/ref/libC -lC_CPD_LIB -L/home/dgogoasa/product/obj_i386-pc-linux2.4/AGDL/ref/libC -lC_PER -L/sde/s_int_r/product/obj_i386-pc-linux2.4/dpr_common/ref/libC -lC_mmi_format -L/sde/s_int_r/product/obj_i386-pc-linux2.4/common/ref/libC -lC_utilC -lC_cdcC -L/sde/taaats_6/case/t_product/taaats/linux_i86/XERCES/xerces-c-obj_2_5_0-linux_i86/lib -lxerces-c -L/sde/s_int_r/product/obj_i386-pc-linux2.4/ubss_src/ref/libc -lbs_linux_i86 -L/sde/taaats_6/case/t_product/taaats/linux_i86/XERCES/xerces-c-obj_2_5_0-linux_i86/lib -lxerces-c -L/sde/taaats_6/case/t_product/taaats/linux_i86/GCC/gcc-3.3.1-i686-Linux2.4.20-8/lib -lstdc++ -L/home/dgogoasa/product/obj_i386-pc-linux2.4/common_cpp/ref/libCxx -lcommon_cpp -L/home/dgogoasa/product/obj_i386-pc-linux2.4/agp_lib/ref/libC -lC_CPD_LIB -L/home/dgogoasa/product/obj_i386-pc-linux2.4/AGDL/ref/libC -lC_PER -L/sde/s_int_r/product/obj_i386-pc-linux2.4/dpr_common/ref/libC -lC_mmi_format -L/sde/s_int_r/product/obj_i386-pc-linux2.4/common/ref/libC -lC_utilC -lC_cdcC -L/sde/taaats_6/case/t_product/taaats/linux_i86/XERCES/xerces-c-obj_2_5_0-linux_i86/lib -lxerces-c -L/sde/s_int_r/product/obj_i386-pc-linux2.4/ubss_src/ref/libc -lbs_linux_i86 -g -lrt -lm -lpthread -shared -o /home/dgogoasa/product/obj_i386-pc-linux2.4/raim/src/libCxx/raim
/usr/bin/ld: /home/dgogoasa/product/obj_i386-pc-linux2.4/raim/src/libCxx/raim:

undefined versioned symbol name
std::basic_string<char, std::char_traits<char>, std::allocator<char> >* std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*>(__gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, __gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, __false_type)@@GLIBCPP_3.2
/usr/bin/ld: failed to set dynamic section sizes: Bad value

doing
nm -C libstdc++.a|grep __uninitialized_copy_aux
results in
std::basic_string<char, std::char_traits<char>, std::allocator<char> >* std::__uninitialized_copy_aux<__gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*>(__gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, __gnu_cxx::__normal_iterator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > const*, std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*, __false_type)

What am I doing wrong?  How can I fix it?
Thank you.
Dan G
dgogoasaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mglxxxCommented:
Why aren't you using g++ to do the link?
0
dgogoasaAuthor Commented:
From I understood gcc calls g++ for C++ and other executables for other languages.  The front end for C++, ADA,C and others is gcc which calls the proper executable accordind to the situation.  
So, again I suppose this is what gcc does anyway . . . but it doesnt explicitly express it in the print outs.
0
jkrCommented:
Seems your compiler/linker version does not match the glibcpp version you are using. Which version of libstdc++.so does the symbolic link in /usr/lib point to?
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

Infinity08Commented:
The first thing that comes to mind is a faulty gcc installation. Try to check that ...
0
mglxxxCommented:
Hmm, it might be true that gcc calls the correct executable when compiling. However, you are using gcc for linking. In order to
know what exactly to do during the link phase, it would need to know in which language the sources for the object files were coded.
I seem to remember error messages similar to the ones you are getting, especially when doing stuff with the STL, when using gcc
instead of g++ for linking.
0
rstaveleyCommented:
Your clue is: "@@GLIBCPP_3.2" with "undefined versioned symbol name" with gcc version 3.3.1.

You are linking in a 3.3.1 standard library, but one or more of your object files has been compiled with 3.2 methinks.
0
dgogoasaAuthor Commented:
- I tried to re-compile with GCC-3.2.3  but I still have the same error.
- libstdc++.so in /usr/lib pointing to ++.so.5.0.3
0
jkrCommented:
Just in case that got lost: Which version of libstdc++.so does the symbolic link in /usr/lib point to?
0
dgogoasaAuthor Commented:
as i mentioned before: libstdc++ symbolic link is pointing to libstdc++.so.5.0.3
0
rstaveleyCommented:
According to http://gcc.gnu.org/onlinedocs/libstdc++/abi.html, libstdc++.so.5.0.3 is gcc-3.2.3, but the GLIBCPP_3.2 symbol is gcc-3.2.0. Can you try it with 3.2.0? It looks like you have one or objects in your link which have been compiled with 3.2.0.

[You'll need to beware of all the *gcc-3.3.1* paths in that link.]
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
dgogoasaAuthor Commented:
I've fixed the problems by doing following things:
- re-compile the code by gcc 3.2.3 ( it doesn't work with gcc 3.3)
- remove the "-L/sde/taaats_6/case/t_product/taaats/linux_i86/GCC/gcc-3.3.1-i686-Linux2.4.20-8/lib -lstdc++" from "gcc ..." command line. ( don't know why)

Thanks for all your help guys.
0
rstaveleyCommented:
> don't know why

You would have been explicitly linking with the 3.3.1 standard library with that path. By removing that from your command line, you would have linked with the default standard library for the 3.2.3 compiler, which would have matched the headers you compiled with.

Well done sorting it out.
0
vanistaCommented:
I've had a similar problem on gcc 3.2 (Red Hat Linux 8.0), but it wasn't caused by a version mismatch in gcc and libstdc++. The project I built used a static Makefile as follows :

CC = gcc
CFLAGS = -g -O3
LDFLAGS = -lstdc++

OBJ = foo.o fun.o

TARGET = libfoofun.so

all: $(TARGET)

%.o: src/%.cpp
        $(CC) $(CFLAGS) -c $< -o $@ $(INCDIR)

$(TARGET):$(OBJ)
        $(CC) -shared -o $@  $(LDFLAGS) $(OBJ)


gcc -shared -o libfoofun.so  -lstdc++  foo.o fun.o
/usr/bin/ld: libfoofun.so: undefined versioned symbol name std::basic_string<char, std::char_traits<char>, std::allocator<char> >& std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, __gnu_cxx::__normal_iterator<char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, char const*, char const*)@@GLIBCPP_3.2
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make: *** [libVANMidi.so] Error 1


I've tracked down the error to the failling ld command :

/usr/bin/ld -v --eh-frame-hdr -m elf_i386 -shared -o libfoofun.so /usr/lib/crti.o /usr/lib/gcc-lib/i386-redhat-linux/3.2/crtbeginS.o -L/usr/lib -L/usr/lib/gcc-lib/i386-redhat-linux/3.2 -lstdc++ foo.o fun.o -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc-lib/i386-redhat-linux/3.2/crtendS.o /usr/lib/crtn.o


Notice that -lstdc++ is placed before the object files? I don't understand how, but this is what cause the failure. If I simply move this argument after fun.o, the link is successful.This translates directly into the Makefile by moving $(LDFLAGS) at the end of the argument list :

$(TARGET):$(OBJ)
        $(CC) -shared -o $@ $(OBJ) $(LDFLAGS)


It was probably a bug in this version of ld, I just wanted to share this info.

0
rstaveleyCommented:
Try:

CC = g++

You can lose -lstdc++ then.

You ought to open a separate question. This is not related to the original thread.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Software

From novice to tech pro — start learning today.