Re: "Ignoring second definition" warning

[skaller]

On Fri, 23 Sep 2005 17:42:09 +0200, Ulrich Eckhardt wrote:

> mrstephengross wrote:
>> =======================================
>> temp.h: inline int foo() { return 0; }
>> a.cpp: #include "temp.h"
>>        int a() { return foo(); }
>> b.cpp: #include "temp.h"
>>        int b() { return foo(); }
>> =======================================
>> 
> [...]
>> The object files get built fine. Now I want to archive them together
>> into a single .a :
> [..]
>> And I get a warning about how ar is ignoring the second definition of
>> 'foo'. It would appear that the compiler ignored the 'inline' specifier
>> and preserved 'foo' as a symbol in each object file.
> 
> Even an inline function must generate an out-of-line definition, after all
> some other file might want to use it and only have a declaration.
> 
>> I've tried to force gcc to truly inline the functions by playing around
>> with gcc's options (such as -finline-size). So far I've been
>> unsuccessful. 
> 
> Yes, anything else would be wrong for above reasons. You might be able to
> force it to be inline with some attributes added to the function though.
> 
>> Any ideas? 
> 
> Yes, make it a static function.

Ignore the warning. 'ar' is a piece of archaic rubbish ;(

I don't know if your alpha/tru64 (v5) system is using an Elf
linker, but if it is, then the inline function bodies will be placed
in 'common' sections, and the linker will simply ignore one
of the defintions (if that doesn't work, you have broken the
One Definition Rule and it's your fault .. :)

This is for static linkage. For dynamic linkage, even Elf seems
to be broken unless you are vary careful. C++ just doesn't work
very well with dynamic linkage because it places untenable 
requirements on the linker. Whilst Elf linkers are fairly smart
and can merge common sections at link time, doing this in
the presence of run time loading is not so easy, in fact,
it is probably impossible -- and there is no easy way to fix it.

Load time linkage should work but doesn't unless you're very
careful. ALL of these problems revolve around the fact
that C++ requires the compiler to automatically generate
certain things, some of which must be unique .. when
you program is dynamically changing, the uniqueness requirement
simply cannot be met automatically.

In particular, inline definitions -- including all templates --
cannot work. Luckily, uniqueness is only required in a few
cases.

1. Comparing function pointers.
2. Static members of functions and classes.
3. RTTI

older gcc at least is broken on (3). This is due to a bug in the way
gcc handles exceptions, which is possibly a bug in the ABI
specification (not sure). 

But it is definitely broken, as I recently discovered,
at least on the old ABI (I'm running Ununtu Hoary, which
is using the old ABI I believe)

For various purposes it is necessary to determine if two
objects have the same type at run time. This includes:

(a) dynamic casts
(b) typeid
(c) typeinfo scanning
(d) exception catching

The ISO C++ Standard requires the typeinfo be comparable
for equality, with equal typeinfo iff it is the same type.
However equal does NOT mean identical, and gcc gets this wrong.
In particular, if you have more than one RTTI record for
the same type in two shared libraries, and one throws an
exception, and the other tries to catch it, it will fail.

This is clearly because gcc is doing the wrong thing:
for performance it is comparing the addresses of the
typeinfo, instead of using the comparison function.
The comparison could work by comparing the mangled
names of the vtable, which will be the same for
all instantiations .. even if there are distinct
typeinfo records and distinct vtables.

If anyone knows this is fixed in the new ABI I'd be 
particularly interested (since I have a code generator
that relies on ISO C++ features in the generated code,
AND does dlopen() style dynamic linkage ..)

-- 
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net