Re: ld: undefined reference to unused function

[Hans-Bernhard Broeker]

Alexander Bernauer <address@hidden> wrote:

> I think I found a bug in the gnu-linker.

I think you haven't.

> lib2.h   : declares classC
> lib2.cpp : defines classC
> liblib2.a: the library consisting of classC

> lib.h    : declares classA and classB
> lib.cpp  : defines classA and classB
>            classB uses a classC object from lib2
>            classA doesn't
> liblib.a : the library consisting of classA and classB 

> main.cpp  : the main program uses a classA object

> When building the application whithout linking liblib2.a to it, the linker
> complains about undefined references concerning classC. But it should not
> complain, as classC is not needed (as no classB object is ever defined)

That diagnosis is definitely incomplete, and quite certainly wrong.

The usage of library files only clouds the issue here --- you would
get the same behaviour using the .o files directly.

Your problem is that classA and classB are *defined* in the same
source file, and thus in the same .o file, and unless they've changed
that recently, the GNU linker still works at .o file granularity.

Turn on verbose messages from the linker to see what happens.  In a
nutshell main.o needs classA.  So the linker pulls in lib.o (from
liblib.a), which provides both classA and classB, but *needs* classC.
So without the definition of classC from lib2.o (in liblib2.a), the
link must fail.

The solution is, and has been since just about forever, to implement
each atomic piece of functionality that will go into a library in a
separate source file.  I.e. you should have one .cpp file with the
definition of classA, the other with the definition of classB.

-- 
Hans-Bernhard Broeker (address@hidden)
Even if all the snow were burnt, ashes would remain.