[poky] /usr/include/libnl3 or /usr/include

[Jean-Francois Dagenais]

Hi Adrian, all,

> On Mar 4, 2019, at 13:59, Adrian Bunk <bunk at stusta.de> wrote:
> 
> On Mon, Mar 04, 2019 at 11:50:43AM -0500, Jean-Francois Dagenais wrote:
>> 
>> Since libnl does explicitly that it cannot co-exist with it's previous versions:
>> RREPLACES_${PN} = "libnl2"
>> RCONFLICTS_${PN} = "libnl2"
>> 
>> what is the point of the sub-path?
> 
> It's where upstream installs their headers.

I understand that. I meant since in the yocto packaging, we ensure libnl2 cannot
live along side libnl3, in our particular context, wouldn't it make dependents
of the library simpler by making the library look and feel like all the other
libraries yocto packages?

> 
>> Would you receive a patchset which moves libnl's headers files back at /usr/include (or rather: ${includedir}) ?
>> 
>> I suspect this would also set a precedent.
> 
> Diverging libnl from upstream does not sound good to me.

Although I share the general spirit of this philosophy, in the case of yocto, I
would argue diverging from upstream using patches and other "hacks" is quite a
common occurence. I would also argue that the fact that the upstream automake
configuration hard-codes the libnl3 subpath within /usr/include is misplaced.
But that is a debate for another crowd. In poky, we could make the patch which
would make the subpath configurable with a default to libnl3 and submit it
upstream... Thoughts?

> 
> The correct fix would be for wpa_supplicant to use
> "pkg-config --cflags libnl-3.0", and the upstream
> sources are already doing that.

I tried many variations of pkg-config use inspired by all the examples already
present in poky and meta-oe, none worked. I get 

| DEBUG: Executing shell function do_compile
| Package libnl was not found in the pkg-config search path.
| Perhaps you should add the directory containing `libnl.pc'
| to the PKG_CONFIG_PATH environment variable
| No package 'libnl' found



> 
> If this is not working without the hack in wpa_supplicant then it should 
> be fixed there, but it is also possible that this hack is just a leftover
> from ancient wpa_supplicant versions and can simply be removed.

You are correct. I removed the two lines which append paths in the
.config in wpa-supplicant:do_configure and sure enough, it still works on thud
(3541f019a505). I also removed the -I/usr/include/libnl3 in
wpa_supplicant-2.6/src/drivers/drivers.mk and manually poisoned my system's
/usr/include/libnl3/*.h just to be sure. All is fine.

But my problem on my wavemon recipe remains, I cannot get it to work out of the
box. My recipe is inspired from
https://github.com/koenkooi/meta-dominion/blob/master/recipes-wifi/wavemon/wavemon_git.bb
where I tried removing the -I${STAGING_INCDIR}/libnl3 and aclocal.m4 hacks. I
get the "no such file" on #include <netlink/netlink.h>

Any clues?