----- Original message ----- > On 03/20/2012 08:11 AM, Serge Hallyn wrote: > > RTNL_LINK_NOT_FOUND no longer exists in libnl-3.0. It used to be > > defined to -1, but now an index of 0 means does not exist. > > > > Signed-off-by: Serge Hallyn <serge.hal...@canonical.com> > > --- > > configure.ac | 2 +- > > src/dutil_linux.c | 14 +++++++------- > > src/dutil_linux.h | 2 +- > > 3 files changed, 9 insertions(+), 9 deletions(-) > > > > Index: netcf-0.1.9/configure.ac > > =================================================================== > > --- netcf-0.1.9.orig/configure.ac 2011-10-07 13:56:38.000000000 +0000 > > +++ netcf-0.1.9/configure.ac 2011-10-07 14:27:48.668839133 +0000 > > @@ -103,7 +103,7 @@ > > if test "x$with_driver" != "xmswindows" > > then > > PKG_CHECK_MODULES([LIBAUGEAS], [augeas >= 0.5.0]) > > - PKG_CHECK_MODULES([LIBNL], [libnl-1]) > > + PKG_CHECK_MODULES([LIBNL], [libnl-3.0]) > > Ouch. This breaks netcf for all distros that don't yet have libnl 3. > What we really need is glue code that lets us target either the libnl 1 > or the libnl 3 API, so that the person running configure can choose > which API they are targeting.
Agreed. I'm not sure i'm artistic enough to do make pretty, but even debian had to revert this. We have the same problem with libirt. So i'll see if can figure out how - but probably not until later in april. Thanks, -serge _______________________________________________ netcf-devel mailing list netcf-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/netcf-devel
