networkmanager-0.9.4.0-force-libnl1.1-r1.patch shoud be removed from NetworkManager 0.9.6.4. NetworkManager's preferred libnl branch is libnl 3.x. We (upstream) will support libnl 1.x for some time for distributions that still use it and then we will drop it entirely. If there is still a sound reason to prefer libnl1.1 in Gentoo, we should definitely know about it so that we can coordinate reasonable phase out of libnl 1.x support.
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
> The networkmanager ebuild uses libnl 1.1 only if you request wimax support. Are you sure? I don't see anything like that in: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/networkmanager/files/networkmanager-0.9.4.0-force-libnl1.1-r1.patch?view=markup If configure options don't work, we need a proper patch that can be upstreamed. With proper upstream support, $(use_with wimax libnl-1) should work for you. With even better upstream support, you shouldn't even need to use it explicitly. > 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. It may just as well be that other distros don't have users that connect to wimax with NetworkManager. I am bringing this upstream: https://bugzilla.gnome.org/show_bug.cgi?id=687630
(In reply to comment #2) > > The networkmanager ebuild uses libnl 1.1 only if you request wimax support. > > Are you sure? I don't see anything like that in: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/ > networkmanager/files/networkmanager-0.9.4.0-force-libnl1.1-r1. > patch?view=markup The patch only adds "--with-libnl-1" configure switch, which allows building against libnl-1 on a system that has both libnl-1 and libnl-3 installed. The ebuild adds "--with-libnl-1" to the configure call if "wimax" is in USE, and "--without-libnl-1" if "wimax" is not in USE: ECONF="--disable-more-warnings [...] $(use_with wimax libnl-1) $(systemd_with_unitdir)" [...] econf ${ECONF} Having the ebuild handle the logic of which configure switches need to be set together under which conditions is the standard idiom in Gentoo.
> The patch only adds "--with-libnl-1" configure switch, which allows building > against libnl-1 on a system that has both libnl-1 and libnl-3 installed. Of course you're right, at least about the preference. I'm now looking at the resulting code instead of just the patch. It looks like something like this should be pushed upstream. But this patch also removes libnl 2.x support, which is not good. And it looks like it removes libnl 1.x autodetection in case libnl 3.x is not present at all. > The ebuild adds "--with-libnl-1" to the configure call if "wimax" is in USE, > and "--without-libnl-1" if "wimax" is not in USE: This is perfectly correct, given that wimax doesn't work with libnl 3.x. > ECONF="--disable-more-warnings > [...] > $(use_with wimax libnl-1) > $(systemd_with_unitdir)" > [...] > econf ${ECONF} > > Having the ebuild handle the logic of which configure switches need to be > set together under which conditions is the standard idiom in Gentoo. Sure. But this can be handled in a distro-independent way. Gentoo ebuild would then be slightly simpler. If you are familiar with autotools and similar software, you can imagine that in ideal world, Gentoo ebuilds are very simple.
If there's no upstremable patch, I will change it myself. Please keep this bug report open for the next NetworkManager release.
Just pushed to master: commit 423d766b03b94be683bf6f46e92fdd6dfcedd121 Author: Pavel Šimerda <psimerda@redhat.com> Date: Thu Nov 22 16:09:35 2012 +0100 build: implement libnl version selection Until we remove libnl-1.x and libnl-2.x support, it should be possible to choose the libnl version at build time. This is mostly important for testing legacy libnl support but it also helps distributions that ship other tools built agains them. (https://bugs.gentoo.org/show_bug.cgi?id=441750) It will be included in the next release of NetworkManager. Instead of --with-libnl-1, we use --with-libnl=1. --with-libnl=1|2|3 Select libnl version (default: latest available) As far as I understand 'usex', the new configure like could look like: $(eusex libnl-1 --with-libnl=1 --with-libnl=3) Link to patch: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=423d766b03b94be683bf6f46e92fdd6dfcedd121
Current NetworkManager master no longer supports anything older than libnl3. That means for proper wimax support, it is necessary to use: http://cgit.freedesktop.org/~dcbw/wimax-tools/
(In reply to comment #7) > Current NetworkManager master no longer supports anything older than libnl3. > That means for proper wimax support, it is necessary to use: > > http://cgit.freedesktop.org/~dcbw/wimax-tools/ Ah, sorry, it's not current master, it's a branch that will be merged to current master soon.
NetworkManager 0.9.8 hard-depends on libnl >= 3.2.7. See the live ebuild for more details.
No need to backport the fix to older versions.
