Relocation Errors prog: fatal: relocation error: file ./ 
                    symbol bar: referenced symbol not found

Program prog uses, and that library has an unresolved dependency on the symbol bar. You can check for this problem using:

$ ldd -d prog

As outlined in the linker guide

Don't, what ever you do, solve it using LD_LIBRARY_PATH!


Indeed, all beginners know that LD_LIBRARY_PATH is for "cannot open shared object file: No such file or directory" errors, here you'd use LD_PRELOAD ;-)

Nice article btw. I thought non-PIC was a more frequent cause for relocation errors.

Posted by Marc on March 02, 2009 at 02:50 PM PST #

I have a good one for you. It is driving me somewhat mad.

here is a bit of code :

#include <vector>

int main()
std::vector<int> v;

Taken from this page :

If I compile that .. this is what I see :

$ echo $CXXFLAGS
-library=stlport4 -norunpath -R$ORIGIN/../lib -R/opt/csw/lib/$ISALIST -R/opt/csw/lib -L/opt/csw/lib

$ echo $CXX

$ $CXX -V
CC: Sun C++ 5.5 Patch 113817-23 2008/06/24

$ $CXX $CXXFLAGS -o /export/home/dclarke/test/CCtest.out /export/home/dclarke/test/

$ file /export/home/dclarke/test/CCtest.out
/export/home/dclarke/test/CCtest.out: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped

$ elfdump /export/home/dclarke/test/CCtest.out | grep RPATH
[7] RPATH 0x3b3 /opt/csw/lib/$ISALIST:/opt/csw/lib:$ORIGIN/../lib:/opt/csw/lib

$ elfdump /export/home/dclarke/test/CCtest.out | grep RUNPATH
[6] RUNPATH 0x3b3 /opt/csw/lib/$ISALIST:/opt/csw/lib:$ORIGIN/../lib:/opt/csw/lib

$ ldd /export/home/dclarke/test/CCtest.out => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/

Note the complete absence of or unlike the example on that page.

I only look at this because I have a nasty bit of code from an open source project that has taken me a while to get a clean compile with, and you guess it, tons of unresolved symbols are the end result. Nothing as pretty as bar or foo. More like :

symbol not found: __1cDstdFctype4Cc_Cid_


symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___2t6M_v_

and forty ugly brothers all very similar.

This has me perplexed .. and I better go get your book also ( non-sequiter ) just to see what I am doing wrong that even a simple sample bit of code does not compile as it should here.

Posted by Dennis Clarke on March 04, 2009 at 09:08 AM PST #


I've tried to replicate your problem.
CC: Sun C++ 5.5 Patch 113817-22 2007/11/29

CC -library=stlport4 -norunpath -R'$ORIGIN/../lib' -R'/opt/csw/lib/$ISALIST' -R/opt/csw/lib -L/opt/csw/lib
$ ldd a.out => (file not found) => /tmp/../lib/ => /tmp/../lib/ => /tmp/../lib/ => /tmp/../lib/ => /usr/lib/

So it works for me. Hence I'm puzzled as to what the problem could be.

Do you get the same effect if you just do

CC -library=stlport4

Also what Solaris version are you on?



Posted by Darryl Gove on March 04, 2009 at 10:19 AM PST #


A good point! The context this came up in was a bit weird....


Posted by Darryl Gove on March 04, 2009 at 10:20 AM PST #

You're going to scream. Or at the very least let out a strange noise when you see this. Trust me, if it were not for the need to do a really baseline test on really low end hardware for a certain telco user I would not be doing this. Enough of the warning .. here goes :

$ uname -a
SunOS fossil 5.8 Generic_117350-56 sun4m sparc SUNW,SPARCstation-20
$ cat /etc/release
Solaris 8 2/04 s28s_hw4wos_05a SPARC
Copyright 2004 Sun Microsystems, Inc. All Rights Reserved.
Assembled 08 January 2004

Straight CC works :

$ CC -library=stlport4 -o $HOME/test/CCtest.out $HOME/test/
$ ldd -r $HOME/test/CCtest.out => /opt/csw/lib/sparcv8/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/ => /usr/lib/

On a somewhat more modern system :

$ uname -a
SunOS osiris 5.10 Generic_138888-03 sun4u sparc SUNW,Sun-Fire-480R
$ which cc
$ which CC
$ CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-09 2008/12/16
$ ls
$ CC -library=stlport4 -norunpath -o CCtest.out
$ file CCtest.out
CCtest.out: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
$ ldd -r CCtest.out => (file not found) => /lib/ => /usr/lib/ => /lib/ => /lib/ => /lib/ => /lib/
symbol not found: __1cDstdM__node_alloc4BiA_N_M_deallocate6FpvI_v_ (CCtest.out)
symbol not found: __1cDstdM__node_alloc4BiA_L_M_allocate6FI_pv_ (CCtest.out)
$ CC -library=stlport4 -o CCtest.out
$ file CCtest.out
CCtest.out: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped
$ ldd -r CCtest.out => /opt/studio/SOS12/SUNWspro/lib/stlport4/ => /lib/ => /usr/lib/ => /lib/ => /lib/ => /lib/ => /lib/ => /lib/

which look perfect.

So it may be best to ignore me. I am locked in mortal battle with GCC 4.3.3, GNU binutils and GMP/MPFR on old Solaris 8 and yes, a sun4m machine.

I can tell you that the same sources compile and pass all tests with GCC 4.3.3 and GNU binutils 2.19.1 on this hardware and on more modern hardware. It simply will not compile with Studio 12 or any of its earlier generations on any hardware from sun4m up to sun4v. In fact, the hardware is not at issue here at all.

It may be a lost cause but there is this nagging part of me that says a well patched compiler should work on an abacus the same way it works on an IBM 3090 mainframe or a Sun SunFire E25K. That isn't what I see however. The open source people in a few of these projects ( gmp/mpfr etc ) tell me I am seeing a clear compiler bug with Studio but I have yet to lock it down to a root cause. If you wanted to login to the blastwave server farm then I could show you where Studio 12 "blows up" with some code fragments but that would be really taking advantage of your time.

Posted by Dennis Clarke on March 04, 2009 at 11:46 AM PST #

This is one of the things that I deal with :

the argument I hear all the time is that GCC can compile it and thus the problem is Studio. Personally I'm not buying that party line.

If you ever get a spare 15 minutes feel free to pull down the sources to GMP and just try a simple configure, make and then make check with it. The issues will become self evident very quickly.

Posted by Dennis Clarke on March 04, 2009 at 12:55 PM PST #

I know, it actually happens fairly often, with multiple versions of a lib.

Is this the "ube: error: SIGNAL: Compile time floating point exception" thing? I thought you were going to report it as a bug on

Posted by Marc on March 04, 2009 at 04:07 PM PST #

Missing stlport4 link:

Does a static version get picked up?
Which flag makes it go from ldd showing it to it disappearing?
What does LD_OPTIONS=files print out?


If the compiler hits a fatal error, then it's a compiler issue - whatever the input :)

Remove the -o <file.o> and replace it with -P. This will cause the compiler to generate a preprocessed source file <file.i>. You can check that this still reproduces the error. Either report the problem at or mail the file to me and I'll take a look. Include the compile flags, and version.

However Sun Studio 8 is a really old version... so the bug is likely to have been detected and fixed in later versions. The first thing I do with bugs is to check whether they appear in the latest versions.


Posted by Darryl Gove on March 05, 2009 at 05:26 AM PST #

I'm still digging into this. As soon as I have a neatly locked down case which is repeatable then I'll file the bug. I am testing on Solaris 8 with Studio 8 as well as Solaris 9 and Solaris 10 using Studio 12. I applied patch 124861-11 Sun Studio 12: Compiler Common patch for Sun C C++ F77 F95 which addresses 6750087 6772370 6780910. I can't find any info on those bugids at b.o.o but I'm probably looking in the wrong place and should stick with Sunsolve. Regardless, I applied the patch and am about to start a build once again with the stlport4 libs being used. If there is still no joy then I'll find a way to file the bug with enough data that it can be reproduced. Just FYI, I have every major architecture here to test on so that slows me down a bit. I'm going back and forth from sun4m to sun4u and x86 and AMD64 on Solaris 8, 9, 10, as well as SNV boxes here also. I think I may be swimming in Solaris/OpenSolaris revs. 8-)

Posted by Dennis Clarke on March 08, 2009 at 01:53 PM PDT #

Post a Comment:
Comments are closed for this entry.

Darryl Gove is a senior engineer in the Solaris Studio team, working on optimising applications and benchmarks for current and future processors. He is also the author of the books:
Multicore Application Programming
Solaris Application Programming
The Developer's Edge
Free Download


« March 2015
The Developer's Edge
Solaris Application Programming
OpenSPARC Book
Multicore Application Programming