Re: [eigen] Link error: multiple definition of ei_p*** functions

[Manoj Rajagopalan <rmanoj@xxxxxxxxx>]

> have had basically two approaches to work around it:
>  - either make the function have static linkage. Big drawback: this
> means binary code bloat as the resulting executable may have N copies
> of the code of that function, if you linked together N object files.
>  - or mark the function as inline. This fixes the issue nicely, but
> has the unwanted side effect of hinting the compiler toward inlining
> the function. Fortunately it's just a hint, so in cases where that
> would be a really bad idea, the compiler still won't inline it.
>
> ...
>
> Opinions?
>

Why can't we just use the inlining approach only? As you said, depending on 
compilation settings the compiler can decide to inline or create a common, 
globally accessible linkage-instance. Moreover, inlining also does cause code 
bloat though it might not be as severe as in the n-copies case. Also, I think 
compilers are smart enough to inline some of the calls to the same function 
in cases where some pseudo-instruction count is within limits) and link to a 
global copy in the case of other calls where inlining would violate limits so 
it does seem to be a hybrid approach. Is the problem then reduced to trusting 
the compiler itself?

thanks,
Manoj