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. > On May 13, 2016, at 6:20 PM, Hefty, Sean <[email protected]> wrote: > >> I don't know the details of how direct works, but if you must build a >> special hardware specific version of libfabric.so, then those symbols >> must not overlap with the normal full function library symbols. > > Libfabric exports a minimal set of functions. Those are unchanged between > the direct and non-direct builds. Typically, a direct build results in a > provider replacing static inline calls with their own implementation and > exporting additional library symbols. The provider may also replace certain > constants and data structures with hardware specific versions. This is how > the mismatch is showing up. > > For the app developer, they write to a single set of interfaces, and no > source changes are required in order to optimize for different providers. > However, the app is expected to recompile if any changes are made to the > library or provider. Outside of select apps (e.g. benchmarks) running on > exascale class machines, I doubt anyone will use FABRIC_DIRECT. > _______________________________________________ > ofiwg mailing list > [email protected] > http://lists.openfabrics.org/mailman/listinfo/ofiwg -- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
