[cfe-dev] GCC and Clang produce undefined references to functions with vague linkage

[Rafael Espíndola]

Richi asked me to also report a gcc bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808

> But that's pervasively true in C++ — the linker has to eliminate duplicates
> all the time.  Idiomatic C++ code ends up plunking down hundreds, if
> not thousands, of inline functions in every single translation unit.  This is
> already a massive burden for linking C++ programs, particularly in debug
> builds.  Adding a few extra symbols when the optimizer determines that
> it can devirtualize, but declines to inline, is essentially irrelevant.
>
> In fact, it is particularly unimportant because it's very likely that this duplicate
> will be in the same DSO as the vtable.  That means that the first solution
> imposes some extra work on the static linker alone (but again, only when
> devirtualizing a call to a function we don't want to inline!) while preserving
> our ability to reduce work for the dynamic linker (since calls do not rely
> on address equality of the function across translation units).  The second
> solution is an irrevocable guarantee that every symbol mentioned in
> a strong vtable *must* be exported to the whole world.
>
> Also recall that these symbols can already be emitted in arbitrary
> other translation units — we cannot change the ABI to say that these
> symbols are *only* emitted in the file defining the v-table.

I would just like to point out that the ABI could says that they only
*need* to be emitted in the file with the vtable, but yes, for a long
time it would have to support the symbols showing up in other
translation units produce by older compilers.

> Finally, both the language standard and the ABI are clearly designed
> around an assumption that every translation unit that needs an inline
> function will emit it.
>
> John.

Cheers,
Rafael