Question

What’s the difference between the following two declarations? I thought they were equivalent, but the first sample works, and the second does not. I mean it compiles and runs, but the bitmap display code shows blank. I have not stepped through it yet, but am I missing something obvious? GUI_BITMAP is a simple structure describing a bitmap. This is for VC++ 2005, but I think it fails in VC++ 2008 also. Scratching my head on this one…

Sample 1:

extern "C" const GUI_BITMAP bmkeyA_cap_active;
extern "C" const GUI_BITMAP bmkeyA_cap_inactive;

Sample 2:

extern "C" 
{
   const GUI_BITMAP bmkeyA_cap_active;
   const GUI_BITMAP bmkeyA_cap_inactive;
};

Edit: More exploring has shown that the second example is creating the structs, while the first is referring to external structs. The second example should fail to link, since there are two variables at global scope with the same name. But it doesn’t, it sends a zero filled struct to the display code which gives up. Hmmm…..

Edit 2: Running the same code through another compiler (IAR) actually failed to compile on Sample 2, with an error about missing a default constructor. So I’m guessing there is something subtle about the “extern” keyword, structs, and C++ that I don’t get. If the things in extern area were functions the two samples would be identical right?

Answer 1

Your linker may is silently resolving the duplicate symbols behind your back. You might get static libraries from a vendor and have to link them with your program – what is the solution for the situation where you have two such libraries and they both define a common symbol? The linker will just resolve that, choosing one or the other definition, and leaving you to deal with the fallout. How are you handling the link stage of your application? You may have better results if you link .o files directly instead of putting them into intermediate libraries before linking the final application.

This page of the ARM documentation describes the problem well – I expect similar behaviour is happening in your case:

Multiple definitions of a symbol in different library objects are not necessarily detected. Once the linker has found a suitable definition for a symbol it stops looking for others. Assuming the object containing the duplicate symbol is not loaded for other reasons no error will occur. This is intentional and particularly useful in some situations.

Edit: More searching has turned up that this problem is caused because of a violation of the “One Definition Rule“, and as a result the compiler/linker aren’t required to inform you of the problem. That makes your question a duplicate of this one.