On 01/03/2013 01:00 PM, Eric Blake wrote:
in the case libvirt was hitting, multiple files used fwrite,
which in turn meant multiple linkable entries for rpl_fwrite were
emitted when linking things together; but because they weren't marked
'static', the linker didn't like us.
OK, but surely this problem would happen with any extern symbol
that gnulib defines. I.e., it's not a problem specific to
extern inline functions; it's a problem with externs in general.
Isn't the "right" way to handle this, from the gnulib point of view,
the lib-symbol-visibility module? Shouldn't libvirt be using that?
If libvirt was compiled with -fvisibility=hidden then any miscellanous
extern functions that it defined would be local to the libvirt .so,
and wouldn't clash with similarly-named functions in other shared objects.
what we
did for fwrite (avoid inline altogether, and instead use GNU C instead
of Standard C, to get the workaround we wanted) is really all the best
we can do
I hope that's not the case, because it pretty much means
that there's no portable way to use inline functions in
gnulib headers that contribute to shared objects.