bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dependency problem : C++ inheritance & linking...


From: Nick Clifton
Subject: Re: Dependency problem : C++ inheritance & linking...
Date: 08 Jul 2002 09:21:43 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1

Hi Andrea,

> libda.a        which contains code of  "class base"
> libdb.a        which contains code of  "class child" which is a direct
> child of class base.
> main.o        which tries to create an instance of class child.
> 
> The problem is that linking those, ld complains that from method child()
> can't find method base(), which is defined in libda.a.

This sounds like a link order dependency problem.  The linker will not
go back to previous libraries specified on the command line in order
to solve references found in object files extracted from archives
later on in the command line.  So for example if your command line was
something like:

        ld main.o libda.a libdb.a

then, assuming that main.o does not reference 'base' but does
reference 'child', the linker will scan main.o, find the reference to
'child', scan libda.a, find nothing, scan libdb.a, find 'child' and
hence the reference to 'base', and then run out of libraries to scan,
so it will complain about the unresolved reference to 'base'.

This is standard behaviour for the linker.  From the documentation:

   The linker will search an archive only once, at the location
   where it is specified on the command line.  If the archive
   defines a symbol which was undefined in some object which
   appeared before the archive on the command line, the linker
   will include the appropriate file(s) from the archive.
   However, an undefined symbol in an object appearing later on
   the command line will not cause the linker to search the
   archive again.

There are three possible solutions to this problem:

  1.  Reorder your link command line.  eg:

        ld main.o libdb.a libda.a

      This will work provided that there are no objects in libda.a
      that need symbols defined in libdb.a.

  2.  Add a second copy of libda.a to the link line.  eg:

        ld main.o libda.a libdb.a libda.a

      This will work provided that resolving base() in the second
      invocation of libda.a does not then require more symbols to be
      resolved, which are defined in libdb.a.

   3. Use the linkers grouping command line options:

        ld main.o --start-group libda.a libdb.a --end-group

      This will repeatedly search libda.a and libdb.a until there are
      no more unresolved references which either library could
      satisfy.  This method has a significant performance cost
      however, and will not work on AIX systems.

Cheers
        Nick




reply via email to

[Prev in Thread] Current Thread [Next in Thread]