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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list