mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Christian Melki <christian.melki@t2data.com>
To: Jon Bird <jon.bird@gd-ms.uk>
Cc: "ptxdist@pengutronix.de" <ptxdist@pengutronix.de>
Subject: Re: [ptxdist] Building the kernel with a different toolchain
Date: Tue, 26 Aug 2025 21:39:34 +0200	[thread overview]
Message-ID: <41f09f9f-6e6b-4132-9932-e86965db1a62@t2data.com> (raw)
In-Reply-To: <CWLP123MB54124EA52B77F5AEEFC864A8A239A@CWLP123MB5412.GBRP123.PROD.OUTLOOK.COM>

Hello Jon.

Under platformconfig -> architecture -> toolchain you have:

                                    (${PTXCONF_GNU_TARGET}-) compiler prefix
(${PTXCONF_COMPILER_PREFIX}) compiler prefix (kernel)
(${PTXCONF_COMPILER_PREFIX}) compiler prefix (bootloader)

Ptxdist allows you to set different compiler prefixes.
Normally this is just the gnu target prefix for all of the build bits.

You'll also need the softlink to the toolchain. Much like the normal
toolchain softlink.

lrwxrwxrwx  1 christianm christianm    82 aug 18 12:14
selected_toolchain ->
/home/christianm/ptxdist/bin/../x-tools/x86_64-secplatform-linux-gnu/bin

lrwxrwxrwx  1 christianm christianm    82 aug 18 12:14
selected_toolchain_kernel ->
/home/christianm/ptxdist/bin/../x-tools/x86_64-secplatform-linux-gnu/bin

But I don't understand why the need to split the builds would arise.
You're bulding a 32-bit x86 userspace for all ptxdist cares. The kernel
is just a blob. Some issues might arise from building x86 on x86, build
env leaks tend to go less noticed and sometime produce more obscure
errors. The build is against the libc and headers.

Your kernel won't care much. It will run on x86_64 and needs to have
ia32 emulation support if you need pure 32-bit binaries. Ptxdist can
build that just fine.

You will need a cross toolchain with a ia32 libc and all userspace
binaries will need to target the same.
I usually use crosstool-ng to produce such odd or specific target
toolchains. I have not tried to produce a toolchain that targets 32-bit
x86 in a while.

Hope this helps somewhat.
Christian

On 8/26/25 6:11 PM, Jon Bird via ptxdist wrote:
> Hello,
> 
>  
> 
> I’m looking for some ideas on how to sensibly go about setting up a
> PTXdist project that requires the kernel to be build using a different
> toolchain. Specifically, the userland component needs to be 32-bit x86
> running on a 64-bit kernel. I can achieve this via a roundabout route of
> building the kernel outside of PTXdist completely, then having a
> dedicated package which copies across the modules onto the rootfs. As an
> approach that’s fine & is probably the path of least resistance however
> ideally, I’d like to then prevent PTXdist from building the kernel
> itself (currently does it for 32-bit) because that’s just a bit
> pointless. Initially tried just de-selecting the Linux kernel from the
> platformconfig menu however that throws an error immediately:
> 
>  
> 
> ptxdist: error: ptxdist-2022.11.0/rules/pre/kernel.make:
> PTXCONF_KERNEL_VERSION is undefined or empty
> 
> ptxdist: error: ptxdist-2022.11.0/rules/kernel-checks.make:
> PTXCONF_KERNEL_VERSION is empty
> 
> ptxdist: error: ptxdist-2022.11.0/rules/kernel-checks.make: please run
> ptxdist platformconfig and activate the kernel
> 
>  
> 
> The other option of course is whether there is any means of specifying a
> different toolchain for the kernel build, I note there is a “compiler
> prefix (kernel)” option in the platformconfig but that just yields the
> first part of the compiler executable, rather than a complete path to
> where the 64-bit toolchain lives.
> 
>  
> 
> Thanks,
> 
>  
> 
> Jon.
> 
> This message and/or attachments may include information subject to
> General Dynamics Corporate and General Dynamics Mission Systems Security
> and/or IT policies and is intended to be accessed only by authorized
> recipients. Use, storage and transmission are governed by General
> Dynamics and its policies. Contractual restrictions apply to third
> parties. Recipients should refer to the applicable policies or contract
> to determine proper handling. Unauthorized review, use, disclosure or
> distribution is prohibited. If you are not an intended recipient, please
> contact the sender and destroy all copies of the original message.
> 




       reply	other threads:[~2025-08-26 19:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CWLP123MB54124EA52B77F5AEEFC864A8A239A@CWLP123MB5412.GBRP123.PROD.OUTLOOK.COM>
2025-08-26 19:39 ` Christian Melki [this message]
2025-08-27  9:30   ` Jon Bird via ptxdist

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41f09f9f-6e6b-4132-9932-e86965db1a62@t2data.com \
    --to=christian.melki@t2data.com \
    --cc=jon.bird@gd-ms.uk \
    --cc=ptxdist@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox