Solved

Link problem using gcc (C++) on Linux

Posted on 2007-03-25
14
836 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
U.S. Department of Agriculture and Acronis Access

With the new era of mobile computing, smartphones and tablets, wireless communications and cloud services, the USDA sought to take advantage of a mobilized workforce and the blurring lines between personal and corporate computing resources.

 
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
 
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

Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Skype is a P2P (Peer to Peer) instant messaging and VOIP (Voice over IP) service – as well as a whole lot more.
All of the resources available today make learning a new digital media easier than ever-- if you know where to begin. This is a clear, simple guide to a few of the basic digital art mediums and how to begin learning them on your own.
The viewer will learn additional member functions of the vector class. Specifically, the capacity and swap member functions will be introduced.
The viewer will learn how to clear a vector as well as how to detect empty vectors in C++.

803 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