On Wed, Nov 12, 2025 at 09:03:23PM +0100, Nicolas Schier wrote: > On Tue, Oct 14, 2025 at 03:05:15PM +0200, Thomas Weißschuh wrote: > > The current logic to inherit -m32/-m64 from the kernel build only works > > for a few architectures. It does not handle byte order differences, > > architectures using different compiler flags or different kinds of ABIs. > > > > Introduce a per-architecture override mechanism to set CC_CAN_LINK and > > the flags used for userprogs. > > > > Signed-off-by: Thomas Weißschuh <[email protected]> > > --- > > Changes in v2: > > - Rebase and drop already applied patch > > - Disable CC_CAN_LINK if the test program generates warnings > > - Move to architecture-specific logic > > - Link to v1: > > https://lore.kernel.org/r/[email protected] > > > > --- > > Thomas Weißschuh (10): > > kbuild: don't enable CC_CAN_LINK if the dummy program generates > > warnings > > init: deduplicate cc-can-link.sh invocations > > kbuild: allow architectures to override CC_CAN_LINK > > riscv: Implement custom CC_CAN_LINK > > s390: Implement custom CC_CAN_LINK > > powerpc: Implement custom CC_CAN_LINK > > MIPS: Implement custom CC_CAN_LINK > > x86/Kconfig: Implement custom CC_CAN_LINK > > sparc: Implement custom CC_CAN_LINK > > kbuild: simplify CC_CAN_LINK > > > > Makefile | 8 ++++++-- > > arch/mips/Kconfig | 15 +++++++++++++++ > > arch/powerpc/Kconfig | 15 +++++++++++++++ > > arch/riscv/Kconfig | 11 +++++++++++ > > arch/s390/Kconfig | 11 +++++++++++ > > arch/sparc/Kconfig | 11 +++++++++++ > > arch/x86/Kconfig | 11 +++++++++++ > > init/Kconfig | 7 +++++-- > > scripts/Kconfig.include | 3 +++ > > scripts/cc-can-link.sh | 2 +- > > 10 files changed, 89 insertions(+), 5 deletions(-) > > --- > > base-commit: 10f8210c7a7098897fcee5ca70236167b39eb797 > > change-id: 20250813-kbuild-userprogs-bits-03c117da4d50 > > > > Best regards, > > -- > > Thomas Weißschuh <[email protected]> > > > > Thanks for the patch set and all the work behind! I found only one > issue in patch 3, the rest looks good to me as they are. > > I haven't reviewed the compiler flags for the archs, but from the formal > point of view they look good to me, too. > > How shall we proceed with here? I think, easiest would be if we get > appropriate acks from the architecture maintainers, so we could take > this via kbuild.
That would surely be the best option. Unfortunately quite frequently it is hard to get architecture maintainer's feedback on a cross-architecture series. > Other opinions? It would also work to only take the first three patches through the kbuild tree and push the other ones through the architecture trees. I don't really have a clear preference. Thomas
