wpa_supplicant: links against libnl-1.1 even though ebuild is looking for slot 3 |
|||||||
Issue description
The ebuild claims it depends on libnl 3:
CDEPEND="
...
kernel_linux? (
...
dev-libs/libnl:3
...
But a running system shows that it linked against 1.1:
localhost ~ # ldd /usr/sbin/wpa_supplicant
...
libnl.so.1 => /usr/lib/libnl.so.1 (0xf6889000)
It seems that we're relying on an independent ebuild bringing in the appropriate package. This causes problems on non-standard builds (e.g., whirlwind testbed-ap profile) where we don't end up including libnl-1.1 on the base image.
Also, wpa_supplicant will fail to compile if I do this first:
emerge-${BOARD} --unmerge dev-libs/libnl-1.1-r1
I hacked around the wpa_supplicant ebuild a bit, but I couldn't quite hack something up. I'm tempted to just rewrite the dependency to say we need slot 0...
,
Apr 4 2017
,
Apr 4 2017
we used to use the newer libnl until it was changed here: https://chromium-review.googlesource.com/331761 due to a bug detailed in issue 591094 . but the change looks like (imo) a workaround rather than a fix for the underlying issue. so either we re-add CONFIG_LIBNLxx settings to select the newer libnl (and fix the original bug properly), or we change it to depend on the older version (and maybe fix the original bug properly in the future?).
,
Apr 4 2017
Thanks for the background Mike. Makes sense. So it's our CHROMIUM hacks to wpa-supplicant that don't play nicely with libnl-3? I'm not sure I'd be able to quickly fix that, but it does seem worth doing. Fixing up the dependency seems like a good immediate step, unless somebody has better insight than I do. I could at least file a follow-up bug for the upgrade.
,
Jun 1 2017
Brian - I've earmarked this as a possible starter bug for ecgh@ Let me know if that works.
,
Jun 1 2017
SGTM. For context: at one point this was important to me (if we cared about being able to still build a testbed-ap image for jetstream from source -- for use with Wifi autotests), but it fell off my radar, as we're still OK with lugging around an old image build. Would be good to resolve eventually. And in case this wasn't clear: Trivial fix: change the slot dependency in the ebuild, to be accurate Bigger problem: upgrade libnl, without regressing, e.g., bug 591094
,
Jun 19 2017
I'll do the quick fix to set slot 0, and I've created issue 734750 for upgrading libnl.
,
Jun 28 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/a9c5cb8c1c819fca7a105229671b165deb23d4d3 commit a9c5cb8c1c819fca7a105229671b165deb23d4d3 Author: Edward Hill <ecgh@chromium.org> Date: Wed Jun 28 21:45:11 2017 wpa_supplicant: fix libnl dependency to be slot 0 wpa_supplicant links against libnl-1.1, so change the ebuild to match (depend on libnl:0 instead of libnl:3) BUG= chromium:708246 TEST=emerge-pyro --unmerge dev-libs/libnl emerge-pyro wpa_supplicant wifi still works on pyro Change-Id: Ife53bd81740c9c42cd78c281abcea1730fed3fc0 Reviewed-on: https://chromium-review.googlesource.com/540185 Commit-Ready: Edward Hill <ecgh@chromium.org> Tested-by: Edward Hill <ecgh@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> [modify] https://crrev.com/a9c5cb8c1c819fca7a105229671b165deb23d4d3/net-wireless/wpa_supplicant/wpa_supplicant-9999.ebuild
,
Jun 29 2017
Fixed I guess? Potential follow up on bug 734750
,
Jul 5 2017
,
Jan 22 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by briannorris@chromium.org
, Apr 4 2017