Re: [OE-core] [PATCH 1/2] systemd: Allow native build

["Böszörményi Zoltán" <zboszor@gmail.com>]

2023. 03. 31. 11:39 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org írta:
> 2023. 03. 30. 18:39 keltezéssel, Richard Purdie írta:
>> On Thu, 2023-03-30 at 16:10 +0200, Alexander Kanavin wrote:
>>> On Thu, 30 Mar 2023 at 16:08, Zoltan Boszormenyi <zboszor@gmail.com> wrote:
>>>> Please see the MR:
>>>> https://gitlab.freedesktop.org/libfprint/libfprint/-/merge_requests/431
>>>>
>>>> udev (provided by systemd) -> libgudev -> libfprint
>>>> also:
>>>> udev-native -> libgudev-native -> libfprint-native -> libfprint
>>>>
>>>> Also, please read the TODO part of the patch for systemd
>>>> and consider it.
>>> We can simply direct libfprint to run its own target pieces under qemu
>>> usermode, and avoid all this nasty native stuff. Meson has direct
>>> support for it, and even if it doesn't work, libfprint can be patched
>>> to use a custom 'wrapper' for executing the binaries.
>> Before we jump to using qemu user mode, the first question has to be do
>> we really need a libgudev native to make libfprint-native work enough
>> to build libprintf.
>>
>> I'd hope the answer is no, we don't as we don't want the build systems
>> udev setup/devices leaking into a target build.
>>
>> We intentionally try and keep native dependencies minimal and needing
>> native udev/systemd versions of things sets of warnings in my mind and
>> in others since it often means we're doing things we shouldn't be or
>> don't actually need.
>>
>> I appreciate there are issues with systemctl-native but those are
>> separate issues and should be addressed as such. Complicating the build
>> dependencies unnecessarily is bad and we should minimise them where
>> possible. it isn't that I didn't read that bit of the patch, I just
>> don't see it as a reason to have this dependency for libfprint.
>>
>> So, I come back to the question of what libfprint needs from libfprint-
>> native and whether it really does need udev for that?
>
> libfprint needs two generator executables to create
> a set of udev rules and another file called autosuspend.hwdb.
>
> Both executables are linked with the complete libfprint library
> which includes the complete set of drivers that are configured
> and built. They seem to need this to deduce the list of supported
> device USB IDs for the current build. Both executables use fpi_
> prefixed functions to ask the libfprint library for their goals.
>
> In turn, the libfprint library depend on libgudev and libgusb
> for hotplug and device discovery purposes, respectively.
>
> There is also a meson bug that Alexander Kanavin brought
> to my attention where custom_target() doesn't run executables
> using the exe_wrapper and I seem to be hitting this with
> libfprint.
>
> I am not a meson expert so if there's a way to replace
> the executable()+custom_target(capture: true) combination
> with something more cross-compiler friendly, please don't hold
> this information back.
>
> I couldn't fix this for libfprint 1.0 / fprintd 0.9.0 two years ago
> and I cannot fix it for the 2.0 beta versions either.
> In my current in-house solution there's a separate systemd-native.bb
> recipe but I thought maybe cleaning it up for upstream and
> modifying the systemd recipe may be acceptable.

Regarding my attempts to fix this: I have looked into
making these executables use "native: true" but it
would need duplicating all the driver and library targets
with "native: true", too, and it seemed to be too intrusive.
Also, it doesn't eliminate the native dependency chain,
building these executables would still need systemd-native,
libgudev-native and libgusb-native.

>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#179406): https://lists.openembedded.org/g/openembedded-core/message/179406
> Mute This Topic: https://lists.openembedded.org/mt/97950749/3617728
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [zboszor@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>