Summary: | [Tracker] Cross compilation support | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Richard Yao (RETIRED) <ryao> |
Component: | Current packages | Assignee: | Cross compilation support <cross> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ale, alexander, bertrand, chewi, dschridde+gentoobugs, herrtimson, joakim.tjernlund, perfinion, sam, slyfox |
Priority: | Normal | Keywords: | Goal, Tracker |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 378559, 472230, 610772, 662720, 317337, 417129, 472234, 627126, 662722 | ||
Bug Blocks: |
Description
Richard Yao (RETIRED)
2018-08-03 13:40:20 UTC
I feel like this bug report is expecting me. :) I have previously covered most of your points in the cross-boss README as this project aims to deal with a lot of these issues in ways that may be too ugly to fix properly in Gentoo itself. Having said that, since becoming a dev and getting improvements in with EAPI 7, I am more confident that cross-boss will eventually not be needed. I am already making vast changes to it that aren't quite ready yet, hence the lack of commits since 2015. The last major issue is Python paths. I'm close now but was distracted by the arm 17.0 profile migration. https://github.com/chewi/cross-boss Unfortunately the vast majority of 1-6 boils down to "autotools is broken." The possible solutions are to either 1) build on the target for the target, 2) test against a system which is not the target, or 3) provide static configuration. To explain the situation as best as possible: #1 is a nonstarter as an increasing number of systems running Linux were not meant to self-host, nor will many of those systems likely ever be capable of doing so in any meaningful way. #2 is redundant as duplicating a virtual target as accurately as one would need implies the completion of #3. The project using a build system should probably need to know the impact of the results of a feature test on the codebase. This is ignoring that typical methods of #2 (qemu-user) are often very slow. Static configuration can be emulated already by providing the configuration test answers, but this does not solve the issue of (future) projects which using the broken tests eventually resulting in a failure that needs to be fixed by someone else. Some autotools developers seem to be against supporting static configuration any more than the project already does. Custom build systems are the minority but typically have the same failures as autotools. To solve all of this efficiently the upstream of each affected package would need to participate. When fixing autotools issues it would be wise to see if they can be solved by properly implementing the cross build functionality. Most tests seem to ignore it. Cheers, R0b0t1 (In reply to James Le Cuirot from comment #1) > I feel like this bug report is expecting me. :) I have previously covered > most of your points in the cross-boss README as this project aims to deal > with a lot of these issues in ways that may be too ugly to fix properly in > Gentoo itself. Having said that, since becoming a dev and getting > improvements in with EAPI 7, I am more confident that cross-boss will > eventually not be needed. I am already making vast changes to it that aren't > quite ready yet, hence the lack of commits since 2015. The last major issue > is Python paths. I'm close now but was distracted by the arm 17.0 profile > migration. > > https://github.com/chewi/cross-boss You might like the following patch, although I need to modify the new statx syscall to support more architectures than just aarch64 before I send it upstream: https://paste.pound-python.org/show/OOGzaK2xgQqH09h0ZY38/ (In reply to R030t1 from comment #2) > Unfortunately the vast majority of 1-6 boils down to "autotools is broken." I wouldn't call it autotools being broken. The developers simply used it in a bad way. > Custom build systems are the minority but typically have the same failures > as autotools. All autotools-based build systems are custom. You need to write some code to make it do the right thing for your project. This is where the issues tend to be. > To solve all of this efficiently the upstream of each affected package would > need to participate. When fixing autotools issues it would be wise to see if > they can be solved by properly implementing the cross build functionality. > Most tests seem to ignore it. Many autotools based packages cross compile without an issue. autotools is not the issue here. I suggest renaming this bug to more explicitly reflect the effort to fix packages and not Gentoo itself. Separate tracker to fix Gentoo's core would make sense as well. user.eclass need fixing useradd and friends to use --prefix PREFIX_DIR so it works on the cross traget and not on the host. fixing libtool bug https://bugs.gentoo.org/655820 would be good too |