[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Trouble with relocation errors
From: |
Sandra Carney |
Subject: |
Trouble with relocation errors |
Date: |
Thu, 2 Jan 2003 21:49:57 -0600 (CST) |
Memo
========================================================================
Date: January 02, 2003
To: GNU Runtime Loader Support
Cc: Duane Herberg
Sean Johnson
Yuriy Malinin
Jerry Pendergraft
Subject: ld.so
========================================================================
012345678012345678901234567890123456789012345678901234567890123456789901
< Synopsis >
The runtime loader complains about an unresolved entry that is
being referenced by a function( func1() ) in the
library( libFunc.so ) even though, func1(), itself is never
referenced.
< Description >
We build a shared library using the object files, 'lib_func1.o',
'lib_func2.o', and 'lib_func3.o'.
We also build two small libraries --
1. libSLCException.so consists of lib_SLCException.o
and that is it.
2. libRtti.so consists of 'lib_SLCRtti.o' and 'lib_SUBRtti.o'.
The files are --
lib_func1.C / lib_func1.h
This defines a function, func1(), which sets up a try
block where an SLCException object is thrown under
certain conditions.
lib_func2.C / lib_func2.h
This is just a generic function that does a printf. Just
their to demonstrate that the code compiles and builds
correctly.
lib_func3.C / lib_func3.h
This actually sets up a function which accepts a reference
to an object of type SLCrtti. Then func3 passes an SLCrtti
reference and a SUBrtti reference to a function, printType.
The prototype for printType accepts a reference of type
SLCrtti. Here RTTI is used to probe the identity of the
objects. It was thought that RTTI might be the issue.
This demonstrates that it is not.
If in the main program, main_foo.C, we comment out the
call to this function, the #include AND do not link
the library to with lib_SLCrtti.o and lib_SUBrtti.o belong,
the runtime loader does not complain. Note that
these objects are not being used in conjunction with
exceptions.
lib_SLCException.C / lib_SLCException.h
This specifies a simple little class called SLCException
to be thrown in a try block. It has a constructor,
destructor, copy constructor and assignment operator.
lib_SLCrtti.C / lib_SLCrtti.h
lib_SUBrtti.C / lib_SUBrtti.h
This specifies and defines the base class, SLCrtti.
They don't actually use RTTI. This class plus it's
subclass, SUBrtti, are instantiated in func3() where
RTTI is used to probe these objects.
main_foo.C
This can call func1(), func2(), and func3().
The experiment can be run several ways :
1. (a) Have main_foo.C call func1(), func2() and
func3().
(b) Link libFunc.so, libRtti.so, and
libSLCException.so during the build.
(c) Run 'doit'. Everybody is happy.
2. (a) Comment out the call to func3() in main_foo.C
while retaining the calls to func1() and func2().
(b) Link libFunc.so and libSLCException.so during
the build.
(c) Run 'doit'. Everybody is happy even though
we are not linking libRtti.so. This is
because we are not referencing func3() so the
loader recognizes that libRtti.so is not
needed and doesn't complain.
3. (a) Comment out the call to func1() in main_foo.C
while retaining the calls func2() and func3().
(b) Link just libFunc.so and libRtti.so during the
build.
(c) Run 'doit'. The loader complains about
an unsatisfied external. When we demangle
the symbols, it is complaining about
~SLCException() being unresolved.
~SLCException() should only come into play
whence func1() is referenced which it is not.
(d) We found that if we either inlined the destructor
or just didn't provide an explicit one, the
problem goes away.
Makefile
Specifies build procedures. Note the flags we use
to compile on Linux and SGI :
IRIX64_CC = CC
IRIX64_CC_libflags = -I. -c
IRIX64_CC_exeflags = -g -I. -c
IRIX64_LD = CC
IRIX64_dso_flags = -Wl,-elf -shared -Wl,-rdata_shared -Wl,-exports
IRIX64_LDflags =
#IRIX64_libs = -L. -lFunc -lRtti -lSLCException
IRIX64_libs = -L. -lFunc -lRtti
Linux_CC = g++
Linux_CC_libflags = -g -I. -fpic -c
Linux_CC_exeflags = -g -I. -fPIC -c
Linux_LD = g++
Linux_LDflags = -Wl,-E -Wl,--allow-shlib-undefined
Linux_dso_flags = -Wl,-shared
#Linux_libs = -L. -lFunc -lRtti -lSLCException
Linux_libs = -L. -lFunc -lRtti
Now, we can build this on an SGI and successfully run it if we set
_RLD_ARGS to "-ignore_unresolved". There IS an unresolved reference
in a function in libFunc.so but even if that particular
function( func1() ) is never referenced by 'doit' so it should
not stop the execution. The result of running 'doit' on
the SGI is :
Hello func2
slc user : rtti
sub user : SUB_rtti
Type of rtti_user is SLCrtti
Type of rtti_user is SUBrtti
SLCrtti : freeing rtti_name and ( vicariously ), bar
SUBrtti destructor : freeing foo
SLCrtti : freeing rtti_name and ( vicariously ), bar
The result of building and running on a RedHat system using the GNU
runtime loader, ld.so, is :
(port5-esi)<720%> doit
doit: relocation error: ./libFunc.so: undefined symbol: _._12SLCException
If we demangle this symbol, it is ~SLCException().
< Software >
gcc : we tried version 2.96 and version 3.2.1( released on 11/20/02 ).
GNU ld : version 2.11.93.0.2 20020207
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute
it under the terms of the GNU General Public License.
This program has absolutely no warranty.
libc : libc-2.2.5.so
ld.so : ld-2.2.5.so
< OS >
RedHat Linux version 7.3
Linux port5 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 i686
< Files >
They are being attached in a tarfile.
unresolved.tar
Description: Binary data
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Trouble with relocation errors,
Sandra Carney <=