Solved

Link problem using gcc (C++) on Linux

Posted on 2007-03-25
14
828 Views
Last Modified: 2013-12-13
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
0
Comment
Question by:dgogoasa
  • 4
  • 4
  • 2
  • +3
14 Comments
 
LVL 9

Expert Comment

by:mglxxx
ID: 18791319
Why aren't you using g++ to do the link?
0
 

Author Comment

by:dgogoasa
ID: 18792466
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
 
LVL 86

Expert Comment

by:jkr
ID: 18793176
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
 
LVL 53

Expert Comment

by:Infinity08
ID: 18793200
The first thing that comes to mind is a faulty gcc installation. Try to check that ...
0
 
LVL 9

Expert Comment

by:mglxxx
ID: 18794728
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
 
LVL 17

Expert Comment

by:rstaveley
ID: 18800065
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
 

Author Comment

by:dgogoasa
ID: 18821519
- 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
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 86

Expert Comment

by:jkr
ID: 18821627
Just in case that got lost: Which version of libstdc++.so does the symbolic link in /usr/lib point to?
0
 

Author Comment

by:dgogoasa
ID: 18821659
as i mentioned before: libstdc++ symbolic link is pointing to libstdc++.so.5.0.3
0
 
LVL 17

Accepted Solution

by:
rstaveley earned 500 total points
ID: 18821919
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
 

Author Comment

by:dgogoasa
ID: 18835545
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
 
LVL 17

Expert Comment

by:rstaveley
ID: 18835812
> 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
 

Expert Comment

by:vanista
ID: 20421157
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
 
LVL 17

Expert Comment

by:rstaveley
ID: 20421520
Try:

CC = g++

You can lose -lstdc++ then.

You ought to open a separate question. This is not related to the original thread.
0

Featured Post

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Suggested Solutions

Today companies are subjected to more-and-more data, and it won't stop any time soon.  But there are obvious opportunities for reducing data, particularly data duplicated among companies.
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
This video will demonstrate how to find the puppet warp tool from the edit menu and where to put the points to edit.
Using Adobe Premiere Pro, the viewer will learn how to set up a sequence with proper settings, importing pictures, rendering, and exporting the finished product.

758 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now