Re: New kmod {libdir} breaks udev, systemd build

Re: New kmod {libdir} breaks udev, systemd build

[Thilo Fromm]

Hi there,

[...]

>> Take meta-openembedded/meta-oe/recipes-core/udev/udev_182.bb, for
>> example. The build predictably fails with
>>
>> checking for KMOD... no
>> configure: error: Package requirements (libkmod >= 5) were not met:
>>
>> No package 'libkmod' found
>>
>>
>> So what's the right thing do do here? Use a different package install
>> path for libkmod, or point udev to /lib/pkgconfig by extending its
>> PKG_CONFIG_PATH correspondingly?
>
> I have some build failure.

Me too. systemd is failing to build for the same reason. For a quick
fix-ish workaround try adding

PKG_CONFIG_PATH =
"${PKG_CONFIG_DIR}:${STAGING_DATADIR}/pkgconfig:${PKG_CONFIG_SYSROOT_DIR}/${base_libdir}/pkgconfig/"

(^^ supposed to be one single line ^^)

to both systemd and udev recipes. Yes, I know, this is a very ugly
hack. I'm still waiting for a response to my either-or question in
this mail thread's first mail before submitting a patch to fix the
issue.

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle

Re: New kmod {libdir} breaks udev, systemd build

[Marko Lindqvist]

On 14 May 2012 15:48, Thilo Fromm <fromm@dresearch-fe.de> wrote:
> Hi there,
>
> [...]
>
>>> Take meta-openembedded/meta-oe/recipes-core/udev/udev_182.bb, for
>>> example. The build predictably fails with
>>>
>>> checking for KMOD... no
>>> configure: error: Package requirements (libkmod >= 5) were not met:
>>>
>>> No package 'libkmod' found
>>>
>>> So what's the right thing do do here? Use a different package install
>>> path for libkmod, or point udev to /lib/pkgconfig by extending its
>>> PKG_CONFIG_PATH correspondingly?
>>
>> I have some build failure.
>
> Me too.

  Worked for me until I enabled meta-openembedded/meta-oe layer for
unrelated reason. Wouldn't behavior meet least-surprise goals better
if openembedded-core version of udev would be the default one
regardless of what additional layers one enables/disables, and meta-oe
version to be the one one has to request explicitly?


 - ML

Re: New kmod {libdir} breaks udev, systemd build

[Thilo Fromm]

Hello,

>>>> Take meta-openembedded/meta-oe/recipes-core/udev/udev_182.bb, for
>>>> example. The build predictably fails with
>>>>
>>>> checking for KMOD... no
>>>> configure: error: Package requirements (libkmod >= 5) were not met:
>>>>
>>>> No package 'libkmod' found
>>>>
>>>> So what's the right thing do do here? Use a different package install
>>>> path for libkmod, or point udev to /lib/pkgconfig by extending its
>>>> PKG_CONFIG_PATH correspondingly?
>>>
>>> I have some build failure.
>>
>> Me too.
>
>  Worked for me until I enabled meta-openembedded/meta-oe layer for
> unrelated reason. Wouldn't behavior meet least-surprise goals better
> if openembedded-core version of udev would be the default one
> regardless of what additional layers one enables/disables, and meta-oe
> version to be the one one has to request explicitly?

openembedded-core only features udev-164 (vs. -182 in meta-oe). -164
in oe-core does not use libkmod, so there's no issue with libkmod in
oe-core. It's no surprise that it "worked for you", you were building
anicent tools.

Try building any tool in oe-core which requires libkmod (and therefore
will go look for libkmod's pkgconf file). If there is such a thing, it
will fail to build. Because kmod installs it .pc file to the wrong
place.

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle

Re: New kmod {libdir} breaks udev, systemd build

[Marko Lindqvist]

On 14 May 2012 20:23, Thilo Fromm <fromm@dresearch-fe.de> wrote:
>
> openembedded-core only features udev-164 (vs. -182 in meta-oe). -164
> in oe-core does not use libkmod, so there's no issue with libkmod in
> oe-core. It's no surprise that it "worked for you", you were building
> anicent tools.

 I know. I were asking why versions are setup like this. If -182 makes
more sensible default, why it's not one in -core. My main point was
that seemingly unrelated change to build xterm to my image (requiring
meta-oe layer) caused *default* udev version to change (I'm not
setting PREFERRED_VERSION anywhere). Shouldn't -core versions be the
default ones, that one may override?


 - ML

Re: New kmod {libdir} breaks udev, systemd build

[Thilo Fromm]

Hello,

>> openembedded-core only features udev-164 (vs. -182 in meta-oe). -164
>> in oe-core does not use libkmod, so there's no issue with libkmod in
>> oe-core. It's no surprise that it "worked for you", you were building
>> anicent tools.
>
>  I know. I were asking why versions are setup like this. If -182 makes
> more sensible default, why it's not one in -core. My main point was
> that seemingly unrelated change to build xterm to my image (requiring
> meta-oe layer) caused *default* udev version to change (I'm not
> setting PREFERRED_VERSION anywhere). Shouldn't -core versions be the
> default ones, that one may override?

I don't know; this is more of a political decision. If oe-core should
be the default then oe-core should always provide the most current
version, imho. But I'm just a bystander anyways; I think this has to
be resolved between oe-core, meta-oe, and Angstrom (which we happen to
use, too).

Regards,
Thilo

-- 
Dipl.-Ing (FH) Thilo Fromm, MSc., Embedded Systems Architect
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515 932 228   mailto:fromm@dresearch-fe.de
Fax: +49 (30) 515 932 77    http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB 130120 B
Ust.-IDNr. DE273952058
Geschäftsführer: Dr. M. Weber, W. Mögle

Re: New kmod {libdir} breaks udev, systemd build

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 14-05-12 19:42, Marko Lindqvist schreef:
> On 14 May 2012 20:23, Thilo Fromm <fromm@dresearch-fe.de> wrote:
>> 
>> openembedded-core only features udev-164 (vs. -182 in meta-oe). -164 in
>> oe-core does not use libkmod, so there's no issue with libkmod in 
>> oe-core. It's no surprise that it "worked for you", you were building 
>> anicent tools.
> 
> I know. I were asking why versions are setup like this. If -182 makes 
> more sensible default, why it's not one in -core. My main point was that
> seemingly unrelated change to build xterm to my image (requiring meta-oe
> layer) caused *default* udev version to change (I'm not setting
> PREFERRED_VERSION anywhere).

Setting preferred versions is the task of the DISTRO. If the DISTRO doesn't
care about the udev version, it will change if you add different versions to
your stack. If that offends you, switch to another DISTRO.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJPsiGdAAoJEHZqAkdh1vT6qUIP/2l+gdBLEmcr1eNJAXa2brKf
7EpMMNChKurwoBQHJqWUFYWGfFDpTsda02jIV3sB4dZ7DzVCrs4MQrBQYBNvoYhb
/xrjnObNDv12mlVTmBU8mfL9BtkCGdjhEs9lq1WDGO6nTEVnlE3T8+skmoGuDfwV
vq1HejuwMNsM5SaC8/jEHDM41YT5gqDMOViSZhwIfSvCPzJ2dc4An5yq601HEIH4
T+SM+BpGLmUgsW0mMnTXgo61BCHc3DMtV3qVl8V/FJRm92OigWUFWihSE+lv9G6O
URpErYOwYFaQaqZs3Ma3MpBQ3GGj1q2FC0ypJ9PsdU2W4SPZsMxJD7VDg/1HbLzn
tsVQPB2+DILoIjUliq+YAAVERj0rAaGbHw6dvFKuaielYjBkCutj3UICG8i0tTyJ
rtIvK7NbWm9BON3t4EHpuzsmyQ90q24glbKGYsEF1F2ckaXj4TRntDcJPu9Cha/7
OQ3lunZINzRf2xKE/ixzmMvTlhehvhrusuV3QboRg0UBVAFlscjeTuZCf+VpX4SY
GKPEV9GZH/0aZwwQgx3/E/+tcwac+IKc+RGk6b3jU269Dz/ShcHmXsBWlCpw2St7
fNakj0PELguutLMqeEYTJedqUBFpfd6y7oz1upxyMF21EUkBdK9mvEF1OX9XmXhs
tQR8lTJjm8PJZ8doKJjk
=bXQJ
-----END PGP SIGNATURE-----