Created attachment 903481 [details] build.log of aarch64-unknown-linux-gnu-emerge --ask dev-debug/drgn Cross compiling drgn by following https://wiki.gentoo.org/wiki/Cross_build_environment results in this error: checking whether we are cross compiling... configure: error: in `/usr/aarch64-unknown-linux-gnu/tmp/portage/dev-debug/drgn-0.0.27-r1/work/drgn-0.0.27-python3_12/build/temp.aarch64-linux-gnu-cpython-312': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details Traceback (most recent call last): ... subprocess.CalledProcessError: Command '['../../../drgn-0.0.27/libdrgn/configure', '--disable-static', '--enable-python', '--disable-dependency-tracking', '--disable-silent-rules', '--with-libkdumpfile', '--disable-openmp']' returned non-zero exit status 77. This appears to be because of drgn's weird combination of setuptools and autotools, so the ebuild doesn't pass the cross compilation information. Adding CONFIGURE_FLAGS+=" --host ${CHOST}" to src_configure() fixes it. I don't know if this is the proper fix. I'm also welcome to suggestions about how to improve drgn's build system upstream. We're kind of split between the Python and C worlds because we have a ton of code in both languages.
Created attachment 903482 [details, diff] 0001-dev-debug-drgn-fix-cross-emerging.patch
Hi Omar! I think your patch looks right (for now). For completeness, we should do --build and --target too, not that it really matters here. I'll apply that now and then do the two tweaks on top. As for what to do upstream... we've seriously struggled with this sort of thing. Back in the days of distutils (which was not great in itself), everyone sort of YOLO'd setup.pys and there was no formal separation, so people got away with a lot. Now PEP517 requires a specific model from build systems and it's made things a lot harder, even if it is ultimately for the best. We've had to help a lot of people move to the "right" PEP517 backend for them. What we tend to recommend is: * flit_core if your project is pure Python, and * meson-python if your project needs to build some C as well If you were to take up meson-python, you'd be able to remove the autotools component and go all-in, and things should Just Work. This is what e.g. numpy, scpiy have moved to.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0f43ab559b9997b42839ff29f5ea9e5605a0bd14 commit 0f43ab559b9997b42839ff29f5ea9e5605a0bd14 Author: Omar Sandoval <osandov@osandov.com> AuthorDate: 2024-09-21 05:00:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-21 05:28:07 +0000 dev-debug/drgn: fix cross emerging Pass --host to configure. Closes: https://bugs.gentoo.org/939942 Signed-off-by: Omar Sandoval <osandov@osandov.com> Signed-off-by: Sam James <sam@gentoo.org> dev-debug/drgn/{drgn-0.0.27-r1.ebuild => drgn-0.0.27-r2.ebuild} | 1 + 1 file changed, 1 insertion(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f92ea535d4733b2714f97a7181ef8804e3dd4920 commit f92ea535d4733b2714f97a7181ef8804e3dd4920 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-21 05:27:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-21 05:28:08 +0000 dev-debug/drgn: pass --build and --target too for completeness Bug: https://bugs.gentoo.org/939942 Signed-off-by: Sam James <sam@gentoo.org> dev-debug/drgn/drgn-0.0.27-r2.ebuild | 2 ++ 1 file changed, 2 insertions(+)
Thanks for applying the fixes. I appreciate the tip, I will take a look at meson-python.
