Stream: beginners

Topic: is cross compilation possible x86 -> arm64

Artur Swiderski (Nov 28 2022 at 09:52):

In my use it would be very useful feature to have that
Most likely it would be possible to create arm64 linux and compile "natively" using qemu, but it sounds like something cumbersome

Folkert de Vries (Nov 28 2022 at 09:56):

for macos?

Artur Swiderski (Nov 28 2022 at 09:57):

linux x86 -> arm64

Folkert de Vries (Nov 28 2022 at 10:04):

well it is technically possible, but would require some linker additions I think

Folkert de Vries (Nov 28 2022 at 10:04):

we should get there eventually

Folkert de Vries (Nov 28 2022 at 10:05):

@Brendan Hansknecht we use iced to fix up the indirect calls, but that is not essential. Are there other x86_64 specific parts to the elf surgical linker?

Artur Swiderski (Nov 28 2022 at 11:20):

yeah I expected that cross compilation is a little far fetch at this point of development. Anyway I want to share my view on planned use case to give you a little bit of insight into my thought process. I am working with embedded linux right now. Sometimes (and those are rare cases like 3-4/per year) there is some more complicated issue to be fixed. In order to gather some additional information about the problem I introduce some very small c++ application to have better insight, c++ works but there is downside to this. In many cases application itself needs to keep track of some relevant linux statistics to act on those. Ideally I would make pair c++ app <--> some parsing app/s and provide c++ with already parsed result. Normally I would use python for this parsing part (I don't necessarily like python but I can do job fast and with not to much effort ). In this case I can't because linux does not have python, because of resources constraints(for this reason all script languages are eliminated). I know that FP is good for parsing so I looked for some alternatives and for example haskell is just to expensive, after like 2 weeks of trying I was able to create something but it is just to difficult to create something fast, and I want to spend like 2-3 hours for specific task max with not so huge intellectual effort. This is just not possible with languages like haskell. I went through examples of roc applications you provided and I see that this level of complexity suits me( although I haven't go beyond some tutorial examples myself). I see that it may leverage my work process quite a bit. Doing everything in C++ always works but experience is mediocre at times, especially when I am facing some kind of parsing. I just waste to much time and energy for that. The energy I want to invest into actual problem I am solving.. Its the reason why I want cross compilation instead of having setup ubuntu on qemu it's just yet another hurdle on my way.

Folkert de Vries (Nov 28 2022 at 11:23):

a fun alternative here might be to run webassembly. roc has good wasm support and a minimal wasm interpreter is in the works

Artur Swiderski (Nov 28 2022 at 11:39):

seems like it will not work in our target device though

Artur Swiderski (Nov 28 2022 at 11:39):

constraints are quite limiting

Brendan Hansknecht (Nov 28 2022 at 16:04):

we use iced to fix up the indirect calls, but that is not essential. Are there other x86_64 specific parts to the elf surgical linker?

No, i don't think so.

Brendan Hansknecht (Nov 28 2022 at 16:06):

@Artur Swiderski, what do you mean when you say embedded? Is it low level embedded where you don't have a Linux os and have to compile for the specific device in a special way, or is it Linux based embedded like a raspberry pi would be?

Folkert de Vries (Nov 28 2022 at 16:07):

fwiw at work we do plan to use wasm on bare-metal devices

Folkert de Vries (Nov 28 2022 at 16:08):

safer than sending arm32 bytes over the air and having devices execute them

Artur Swiderski (Nov 29 2022 at 11:40):

Brendan Hansknecht said:

Artur Swiderski, what do you mean when you say embedded? Is it low level embedded where you don't have a Linux os and have to compile for the specific device in a special way, or is it Linux based embedded like a raspberry pi would be?

small device but with linux(heavily customized and limited)

Artur Swiderski (Nov 29 2022 at 11:43):

but I believe I can always just create arm64 VM machine and setup rust and roc environment there?

Anton (Nov 29 2022 at 11:49):

We do not run CI tests on arm64 linux, so that may require some small fixes here and there. it's probably not that difficult to get working because we do test on macos arm64.

Artur Swiderski (Nov 29 2022 at 12:13):

btw do roc applications have some hidden dependency line shared librares for a c++ application, or it will just run and is fully portable?

Anton (Nov 29 2022 at 12:51):

These are the dynamically loaded libraries for a roc app with a C platform and for another app using a rust platform:

ldd rocWithCPlatform
    linux-vdso.so.1
    libm.so.6
    libpthread.so.0
    libdl.so.2
    librt.so.1
    libutil.so.1
    libc.so.6
    /lib64/ld-linux-x86-64.so.2

ldd rocWithRustPlatform
    linux-vdso.so.1
    libgcc_s.so.1
    librt.so.1
    libpthread.so.0
    libm.so.6
    libdl.so.2
    libc.so.6
    /lib64/ld-linux-x86-64.so.2

Richard Feldman (Nov 29 2022 at 16:34):

in theory, at a language level Roc is designed to have no C library dependencies - not even libc - so you should be able to make a platform that does not use libc, and everything should be ok

Richard Feldman (Nov 29 2022 at 16:35):

however, in practice LLVM automatically emits things that assume libc is present (e.g. recognizing certain patterns and turning them into memcpy calls) and we don't currently have workarounds for those

Richard Feldman (Nov 29 2022 at 16:36):

so it's an explicit goal to have Roc applications be able to run on platforms that link zero libraries, including libc, but I don't think in practice it's safe to assume that's possible today (and I don't know if it's ever been tested with the LLVM backend!)

Brendan Hansknecht (Nov 29 2022 at 17:01):

but I believe I can always just create arm64 VM machine and setup rust and roc environment there?

Yeah, that should definitely work.

To actually cross compile today, you would have to:

1. use roc build --lib or roc build --no-link to generate a shared library or object file. You can use ar rcs to convert the object file to a static library. Just use --target to target arm64.
2. Modify the platform to cross compile. In doing so, make it depend on the shared or static library from Roc.
3. Send over the binary/shared library

Brendan Hansknecht (Nov 29 2022 at 17:03):

In the future, once an arm64 surgical linker exists, it should be possible to just modify the platform to support an arm64 toolchain. The surgical linker and roc should be able to deal with everything else without any special config.

Brendan Hansknecht (Nov 29 2022 at 17:03):

(e.g. recognizing certain patterns and turning them into memcpy calls) and we don't currently have workarounds for those

Surgical linker is a workaround for platforms that support it

Brendan Hansknecht (Nov 29 2022 at 17:05):

Note on --target, it might need to be expanded to actually support specific arm hardware, but probably works currently with generic arm64 that can run linux.

Artur Swiderski (Nov 29 2022 at 17:11):

I have started to setup qemu based ubuntu, I think I have to little knowledge to hack through compilation and dependency building on my own, to cross compile.

Joshua Warner (Nov 29 2022 at 20:05):

Would it be useful to borrow zig's approach to cross-compilation, where they bundle minimal compressed versions of libc headers / binary stubs for a bunch of platforms?

Brendan Hansknecht (Nov 29 2022 at 22:56):

Probably not. Roc doesn't need to use libc and is totally dependent on the platform to decided what cross compilation is supported.

Last updated: Jul 26 2025 at 12:14 UTC