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.