Re: [PATCH v4] builddeb: generate multi-arch friendly linux-libc-dev package

[Jan Kiszka <jan.kiszka@siemens.com>]

On 20.07.19 22:16, chombourger@gmail.com wrote:
> 
> 
> On Wednesday, July 17, 2019 at 7:47:45 AM UTC+2, Henning Schild wrote:
> 
>     Am Thu, 11 Jul 2019 23:46:53 +0900
>     schrieb Masahiro Yamada <yamada....@socionext.com <javascript:>>:
> 
>      > On Tue, Jul 9, 2019 at 4:44 PM Cedric Hombourger
>      > <Cedric_H...@mentor.com <javascript:>> wrote:
>      > >
>      > > Debian-based distributions place libc header files in a machine
>      > > specific directory (/usr/include/<libc-machine>) instead of
>      > > /usr/include/asm to support installation of the linux-libc-dev
>      > > package from multiple architectures. Move headers installed by
>      > > "make headers_install" accordingly using Debian's tuple from
>      > > dpkg-architecture (stored in debian/arch).
>      > >
>      > > Signed-off-by: Cedric Hombourger <Cedric_H...@mentor.com <javascript:>>
>      > > ---
>      > >  scripts/package/builddeb | 5 +++++
>      > >  scripts/package/mkdebian | 1 +
>      > >  2 files changed, 6 insertions(+)
>      > >
>      > > diff --git a/scripts/package/builddeb b/scripts/package/builddeb
>      > > index b03dd56a4782..d5d33bcba1fb 100755
>      > > --- a/scripts/package/builddeb
>      > > +++ b/scripts/package/builddeb
>      > > @@ -132,6 +132,11 @@ fi
>      > >  if [ "$ARCH" != "um" ]; then
>      > >         $MAKE -f $srctree/Makefile headers_check
>      > >         $MAKE -f $srctree/Makefile headers_install
>      > > INSTALL_HDR_PATH="$libc_headers_dir/usr"
>      > > +       # move asm headers to /usr/include/<libc-machine>/asm to
>      > > match the structure
>      > > +       # used by Debian-based distros (to support multi-arch)
>      > > +       host_arch=$(dpkg-architecture -a$(cat debian/arch)
>      > > -qDEB_HOST_MULTIARCH)
>      > > +       mkdir $libc_headers_dir/usr/include/$host_arch
>      > > +       mv $libc_headers_dir/usr/include/asm
>      > > $libc_headers_dir/usr/include/$host_arch/ fi
>      >
>      >
>      > I just wondered whether there is something better than $(cat
>      > debian/arch), but maybe not.
>      >
>      > OK, I am ready to pick it up for 5.3-rc1.
>      >
>      > With Ben's Ack, I would be able to proceed with more confident.
> 
>     going Isar-only
> 
>     That looks like it will go in. Now would be the time to prepare putting
>     it into Isar-core. I think the patch should be in filesdir of the custom
>     kernel code and should be applied if PV < 5.2.
>     The actual patch should of cause be the one that goes mainline, and the
>     actual PV will depend on when it does. And we might have to carry
>     backports of the patch, should it not apply all the way back to say 4.4
> 
>     I assume the Isar-patch could hold a surprise or two, so starting it
>     early could speed things up. Just keeping the magic in a layer and
>     leaving Isar-core without the fix would not be ideal.
> 
> 
> Here's what the patch may look like (started some test builds)
> I had to adjust the upstream patch twice to support kernels >= 4.0 (and < 5.3)
> 
> The upstream patch should land in 5.3 (it was part of the kbuild pull request #2 
> that was sent to Linus)
> 
> Before submitting this as a formal Patch Review, please let me know if the 
> proposed approach makes sense?
> 
> diff --git a/meta/recipes-kernel/linux/linux-custom.inc 
> b/meta/recipes-kernel/linux/linux-custom.inc
> index ee5f20c..06b4b93 100644
> --- a/meta/recipes-kernel/linux/linux-custom.inc
> +++ b/meta/recipes-kernel/linux/linux-custom.inc
> @@ -16,6 +16,16 @@ python() {
>       kernel_name = d.getVar("KERNEL_NAME_PROVIDED", True)
>       d.setVar('PROVIDES', 'linux-image-' + kernel_name + ' ' + \
>                            'linux-headers-' + kernel_name)
> +    cmp_4_0  = bb.utils.vercmp_string(d.getVar('PV', True), '4.0')
> +    cmp_4_17 = bb.utils.vercmp_string(d.getVar('PV', True), '4.17')
> +    cmp_5_1  = bb.utils.vercmp_string(d.getVar('PV', True), '5.1')
> +    cmp_5_3  = bb.utils.vercmp_string(d.getVar('PV', True), '5.3')
> +    if cmp_5_1 >= 0 and cmp_5_3 < 0:
> +        d.appendVar('SRC_URI', " file://builddeb-libc-multi-arch-5.1-5.2.patch")
> +    elif cmp_4_17 >= 0 and cmp_5_1 < 0:
> +        d.appendVar('SRC_URI', " file://builddeb-libc-multi-arch-4.17-5.0.patch")
> +    elif cmp_4_0 >= 0 and cmp_4_17 < 0:
> +        d.appendVar('SRC_URI', " file://builddeb-libc-multi-arch-4.0-4.16.patch")
>   }
>   inherit dpkg-base
> 

I'm more in favor of informing the users about the problem when building a 
custom kernel and letting them do the integration. I've a patch for that now, BUT...

Even with the patch applied (on 4.19 in my case), I'm still not able to install 
linux-libc-dev:<target-arch> into a buildchroot-host. I suppose you didn't 
target cross-scenarios, did you?

Our problems seems to be that we cannot provide a 
linux-libc-dev:<buildhost-arch> of the same version. So the files that both 
linux-libc-dev packages have in common do not match. Not sure if that is checked 
or if Multi-Arch implies that all packages must have the same version. However, 
this does not work yet.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux