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 _______________________________________________ Help-gplusplus mailing list Help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus