This is a losing battle. We can't keep an up-to-date table in our configury of what downstream packages were compiled with what versions of libnl, not only because it would quickly become out of date, but also because the downstream package may be variable (e.g., libfabric, as I cited in http://www.open-mpi.org/community/lists/devel/2015/08/17818.php).
The best we might be able to hope for is a utility routine: bool opal_libnl_conflicts_present(void); Anyone using libnl services (or using services that use libnl) should call this function before invoking any libel-specific functionality. This function will opal_dl_open(NULL) and look for libnl-specific and libnl3-specific symbols. If found, show_help() an error, and return "true". If the caller gets "true" back, it will know that it cannot call its libnl functionality, and then decide whether it wants to continue or not. This is *not* foolproof; there are likely cases where this will not work. But it may be sufficient / may work in some cases...? (disclaimer: I have not tested this myself) > On Aug 24, 2015, at 9:42 AM, Gilles Gouaillardet > <gilles.gouaillar...@gmail.com> wrote: > > a first step could be adding a --disable-libnl3 option to configure, which > means components should not even try to use libnl3 > > makes sense ? > > On Monday, August 24, 2015, Gilles Gouaillardet > <gilles.gouaillar...@gmail.com> wrote: > iirc, librdmacm uses libnl > > I am not sure if handling this at run time is even possible > > why not handle this at configure time ? > e.g. if a component known to use libnl is built, then make sure no component > uses libnl3 > > On Monday, August 24, 2015, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > It is definitely true that if both libnl v1 and libnl v3 (also known as > "libnl3", even though libnl v1 is known as "libnl") are present in the same > process, Random Bad Things will happen. This is due to unfortunate choices > that the netlink library authors and/or packagers made. > > From what I have heard, the world is moving to libnl3, but this is a change > that will take time. > > The usnic BTL uses libfabric; the usnic provider in libfabric can use either > libnl or libnl3. I don't know what else in OFED uses libnl -- perhaps IBoIP > (aka RoCE)? > > We've talked about this internally. But sadly, we haven't come up with a > good+reliable way to run-time detect if both libnl and libnl3 are present in > the same process (e.g., if some of OMPI's dependent libraries pull them both > in). We could try to opal_dl_open() NULL and them look for symbols that are > unique to libnl and libnl3, but a) when to do that, and b) it's not > guaranteed to work in all cases. > > > > > > On Aug 24, 2015, at 7:36 AM, Gilles Gouaillardet > > <gilles.gouaillar...@gmail.com> wrote: > > > > Folks, > > > > I recently installed libnl3-devel rpm on my centos 7 box, reconfigured and > > recompiled ompi, and ompi_info now crashes. > > > > it seems the root cause is an obscure conflict between libnl and libnl3. > > libnl is indirectly required by the common_verbs mac (OFED libraries do > > need it) and libnl3 is required by reachable_netlink mca when available. > > > > currently, there are two workarounds available > > 1. uninstall libln3-devel rpm, so reachable_netlink mca uses libnl > > 2. configure with --without-verbs so no mac requires libnl > > > > right now, my best bet would be not to use libnl3 when configure'd with > > --verbs and OFED is available. > > > > any thoughts ? > > > > Cheers, > > > > Gilles > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2015/08/17812.php > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/08/17813.php > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2015/08/17816.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
