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:
On Aug 24, 2015, at 9:31 AM, Gilles Gouaillardet
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
How
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 r
fwiw, in my environment, libnl is loaded before libnl3
the crash occurs in libnl3 initializer, which is invoked when dlopen'ing
mca_reachable_netlink.so
it is very strange since some initialized static structs (same name,
different type and value in both libraries) are incorrectly initialized (or
a
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)
wrote:
> It is definitely
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 ha
