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:

quoted

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 <redacted>
---
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/20250813-kbuild-userprogs-bits-v1-0-2d9f7f411083@linutronix.de (local)

---
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 [off-list ref]

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