> -----Original Message-----
> From: Alexander Kanavin <alex.kana...@gmail.com>
> Sent: 21 October 2024 12:42
> To: Diego Santa Cruz <diego.santac...@spinetix.com>
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] gzip segfault with mandb and qemu when building rootfs
>
> It would help if you replicate the issue on master, and provide steps
> to reproduce so I or anyone else can observe the issue.
I should be able to do that, but it will take me a bit to set up the necessary
time aside. I'll come back when I have it.
>
> Alex
>
> On Sun, 20 Oct 2024 at 14:59, Diego Santa Cruz via
> lists.openembedded.org
> <diego.santacruz=spinetix....@lists.openembedded.org> wrote:
> >
> > Hi there,
> >
> >
> >
> > We noticed many gzip segfault errors on our build machine when doing either
> do_rootfs or do_populate_sdk for images on which the man pages are enabled.
> >
> >
> >
> > We traced this to mandb, run from the postinst script injected by
> manpages.bbclass, which invokes gzip to scan compressed manpages.
> >
> >
> >
> > Our diagnostic is that mandb is executed via qemuwrapper with
> LD_LIBRARY_PATH set to the rootfs lib dirs, which is expected since mandb is
> from the rootfs. However, PATH is not set to the rootfs bin dirs, but instead
> to the
> various sysroots and wrapper paths, so it is gzip from recipe-sysroot-native
> that is
> executed, using ld-linux from the rootfs. But it turns out that the ld-linux
> and libs
> from rootfs are incompatible with those of recipe-sysroot-native, which
> results in
> a segfault in ld-linux.
> >
> >
> >
> > I fixed this in our builds by simply adding -E
> > PATH=$D${bindir}:$D${base_bindir}
> to the qemuwrapper command line in scripts/postinst-intercepts/update_mandb.
> However, I do wonder if the correct fix would not be in qemu.bbclass to
> systematically set that option for any qemuwrapper invocation, as the problem
> can potentially affect any tool executed via qemuwrapper that spawns or execs
> some other executable using PATH to locate it.
> >
> >
> >
> > We encountered this on kirkstone, but our local kirkstone branch has this
> commit backported:
> https://git.opene/
> mbedded.org%2Fopenembedded-
> core%2Fcommit%2F%3Fid%3Dfbd8a57aa307bfda70a08cb78af3c97f05c39a3a&d
> ata=05%7C02%7Cdiego.santacruz%40spinetix.com%7C58fa5a2ba5d74963e0820
> 8dcf1bcfc0a%7C5f4034faed2d4840a93facb1e9633b93%7C0%7C0%7C63865104
> 1185631709%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=o4y7uCZ3
> AqhUoC1RckCnKIiiZHPpS6WMk61KcW0vtEY%3D&reserved=0 Hence the
> modification of scripts/postinst-intercepts/update_mandb and not
> manpages.bbclass
> >
> >
> >
> > The problem does not occur when building images for machines which are not
> x86-64 based, since the build host and target architectures are not
> compatible.
> Note also that the segfault is gone with the above mentioned fix, but gzip
> does
> not run successfully since /bin/gzip from the rootfs is an absolute symlink
> to the
> active alternative (e.g., /bin/gzip.gzip), which does not exist on the build
> host, but
> that is another problem, at least the segfault is gone.
> >
> >
> >
> > Would fixing qemu.bbclass make sense? If yes, how extensive should that be?
> For instance, explicitly passing the right dirs for PATH to
> qemu_wrapper_cmdline,
> like it is done for LD_LIBRARY_PATH? Or just implicitly setting it in
> qemu_wrapper_cmdline?
> >
> >
> >
> > Sincerely,
> >
> >
> >
> > Diego
> >
> >
> >
> > --
> > Diego Santa Cruz, PhD
> > Technology Architect
> > spinetix.com
> >
> >
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#206125):
https://lists.openembedded.org/g/openembedded-core/message/206125
Mute This Topic: https://lists.openembedded.org/mt/109114254/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
