GNOME Bugzilla – Bug 687630
When NM is build --with-wimax, it links to libnl 3.x and to libraries that link to libnl 1.x
Last modified: 2013-05-07 09:04:55 UTC
From gentoo bugzilla: Alexandre Rostovtsev gentoo-dev 2012-11-05 02:52:47 UTC The networkmanager ebuild uses libnl 1.1 only if you request wimax support. If networkmanager is being configured with --enable-wimax, it will link with libiWmxSdk, and libiWmxSdk links with libnl 1.1 If networkmanager then links to libnl-3, it will crash at runtime due to symbol collisions from different libnl versions. I have no idea how other distros managed to avoid this problem. Looking at the Fedora wimax-1.5.2 package, for instance (http://pkgs.fedoraproject.org/cgit/wimax.git/), I don't see any patches to allow using libnl-3 instead of libnl 1.1 https://bugs.gentoo.org/show_bug.cgi?id=441756
(In reply to comment #0) > I have no idea how other distros managed to avoid this problem. Looking at > the > Fedora wimax-1.5.2 package, for instance > (http://pkgs.fedoraproject.org/cgit/wimax.git/), I don't see any patches to > allow using libnl-3 instead of libnl 1.1 wimax gets its libnl dependency from the wimax-tools package, which will compile against either libnl1 or libnl3. The fedora spec files for both wimax-tools and NetworkManager have "BuildRequires: libnl3", so they both get built with that. Probably the right fix for gentoo is to make the wimax ebuild require libnl3. NM's configure should bail out with an error if it would be building against a different libnl from libiWmxSdk though (which would happen on Fedora if you had libnl-devel installed but not libnl3-devel).
> wimax gets its libnl dependency from the wimax-tools package, which will compile against either libnl1 or libnl3 Not as far as I can see. configure.in in wimax-tools-1.4.5 (the latest version) simply does PKG_CHECK_MODULES(LIBNL1, libnl-1 >= 1.0-pre7) There are no checks whatsoever for libnl-3.
ah, indeed, we are apparently using a forked copy of it: http://cgit.freedesktop.org/~dcbw/wimax-tools/
Thanks, but that means upstream wimax or wimax in other distribution has a hard dependency for libnl-1 that implies a hard dependency for NetworkManager. We should probably not depend on distributions to use the forked version, so upstream NetworkManager should default to libnl-1 when wimax is used and it should be overridable by the distribution, of course. The other solution is to upstream patches that add libnl 3.x support to wimax-tools. It might be even a good idea to detect what version is actually used by wimax-tools in the particular case. Another question is, whether this can happen with something else than wimax-tools and what should we do to avoid it.
I think that the best resolution for this bug report would be to detect old wimax tools and either warn or refuse to build unless --with-wimax=unsupported-version or something like that. Crashing is bad if we can avoid it.
Proper solution depends on wimax library versioning. dcbw: Please decide whether you're going to do anything about this or close as WONTFIX.
Yeah, this is a gotcha when building the wimax support. We could do some configure-time magic to run 'ldd' on the wimax library and make sure that the libnl it uses is compatible with the one NM is being built with. Upstream Intel WiMAX stuff is basically dead. I did a lot of work a year or so ago to port the wimax stack to libnl3, and that work is in my freedesktop git repo. I'd suggest that all distros migrate over to my forked repo instead of using the upstream stuff, which hasn't been updated in a very, very long time. So basically, if anyone sees value in doing a dance in configure for libnl version compat checks, then we should keep this bug open and do the work in configure. Otherwise, WONTFIX and it's about education.
Created attachment 243405 [details] [review] 0001-build-error-at-configure-time-if-WiMAX-stack-built-w.patch How about this patch?
Comment on attachment 243405 [details] [review] 0001-build-error-at-configure-time-if-WiMAX-stack-built-w.patch >+# pkgconfig >+AC_PATH_PROG(PKGCONFIG_PATH, pkg-config, no) >+if test x"$PKGCONFIG_PATH" = xno; then >+ AC_MSG_ERROR([pkgconfig required but not found]) >+fi you don't need to do that; it's in $PKG_CONFIG already >+ if test x"$?" != "x0"; then you need either quotes or x's, but both is redundant.
(In reply to comment #9) > >+ if test x"$?" != "x0"; then > > you need either quotes or x's, but both is redundant. And in this case you don't even need either of them.
Fixed up and pushed.
Thanks!