[ofiwg] detecting FABRIC_DIRECT mismatch

[Jason Gunthorpe]

On Fri, May 13, 2016 at 10:36:02PM +0000, Jeff Squyres (jsquyres) wrote:
> How about renaming the output library:
> 
> - if DIRECT is enabled: libfabric_direct.*
> - if DIRECT is not enabled: libfabric.*
> 
> Then there's no symbol collisions, and it's obvious to applications
> which one they should link against.

Often dynamic symbols are not scoped to the library name, so this
helps a little but not fully.

So, the symbols still have to be renamed. In the above case symbol
versions could be used, which makes it a bit more transparent, but
considering FABRIC_DIRECT uses header file magic already I'd think it
would be better to mangle the symbol names in the source.

 #define DIRECT_PROVIDER  _verbs
 #define FABRIC_MANGLE(fn) fn ## DIRECT_PROVIDER
 void FABRIC_MANGLE(fi_foo)(struct fi_foo ## DIRECT_PROVIDER *);
 #define fi_foo fi_foo ## DIRECT_PROVIDER

That makes life easier in future if someone does the work to build a
single libfabric which can support both modes - which seems like the
main precondition to making this feature widely usable...

Jason