Trouble with relocation errors

[Sandra Carney]

                                  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