/usr/include/libnl3 or /usr/include

/usr/include/libnl3 or /usr/include

[Jean-Francois Dagenais]

Hi guys,

There's been a couple of time when I've hit snags where packages use their version numbers in the paths of stuff they provide. This poses a small challenge where dependent recipes might have to specifically account for this "special" path.

For example, libnl is using /usr/include/libnl3 and wpa_supplicant has to specifically "hack" its configure process to be able to find the libnl headers.

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?

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.

Re: /usr/include/libnl3 or /usr/include

[Adrian Bunk]

On Mon, Mar 04, 2019 at 11:50:43AM -0500, Jean-Francois Dagenais wrote:
> Hi guys,
> 
> There's been a couple of time when I've hit snags where packages use their version numbers in the paths of stuff they provide. This poses a small challenge where dependent recipes might have to specifically account for this "special" path.
> 
> For example, libnl is using /usr/include/libnl3 and wpa_supplicant has to specifically "hack" its configure process to be able to find the libnl headers.
> 
> 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.

> 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.

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

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.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: /usr/include/libnl3 or /usr/include

[Jean-Francois Dagenais]

Hi Adrian, all,

> On Mar 4, 2019, at 13:59, Adrian Bunk <bunk@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?

Re: /usr/include/libnl3 or /usr/include

[Jean-Francois Dagenais]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

clue...

> On Mar 5, 2019, at 10:32, Jean-Francois Dagenais <jeff.dagenais@gmail.com> wrote:
> 
> I tried many variations of pkg-config use inspired by all the examples already
> present in poky and meta-oe, none worked. I get 

I got it working with this in my recipe (global scope):

CFLAGS += "`pkg-config --cflags libnl-3.0`"

I still don't get why wpa-supplicant_%.bb works without this.

[-- Attachment #2: Type: text/html, Size: 2463 bytes --]

Re: /usr/include/libnl3 or /usr/include

[Adrian Bunk]

On Tue, Mar 05, 2019 at 10:38:06AM -0500, Jean-Francois Dagenais wrote:
>...
> I still don't get why wpa-supplicant_%.bb works without this.

http://w1.fi/cgit/hostap/tree/src/drivers/drivers.mak#n183

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed