# Porting Julia to new platforms

**URL:** <https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698>\
**Category:** Internals & Design\
**Created:** [November 15, 2024, 10:09pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698 "2024-11-15T22:09:33Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 15, 2024, 10:09pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/1 "2024-11-15T22:09:33Z")

</div>

I cloned the Julia repo to my SmartOS box, intending to build it. I found out that:

- it has a `Makefile`, not a `configure` script or a `CMakeLists.txt` file or the like;
- it failed to build;
- somewhere in the source code, there’s a file with lots of `#define`s relating to specific operating systems.

Is there a porting guide for people who want to get Julia to run on new OSes or processors? Is someone willing to get it to build with CMake or some such build system, to make it easier to port?

Besides illumos, I’d like to get it to run on DragonFly BSD, and I’ve been wanting to buy a big-endian Power box (Talos II, unless they come out with something new by the time I have enough money) running one or more of Adélie Linux (musl), FreeBSD, or OpenBSD to test portability of software I write.

---

<div class="post-metadata">

**Author:** ![savq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/savq/32/22063_2.png) [@savq](https://discourse.julialang.org/u/savq)\
**Post date:** [November 16, 2024, 6:50pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/2 "2024-11-16T18:50:50Z")

</div>

I’d first check whether some of the big dependencies are supported or not in SmartOS.

llvm works on BSDs, and probably Solaris too. But I don’t think libuv supports Solaris (not sure, you’d have to check).

---

<div class="post-metadata">

**Author:** ![woclass](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/woclass/32/212699_2.png) [@woclass](https://discourse.julialang.org/u/woclass)\
**Post date:** [November 17, 2024, 4:49am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/3 "2024-11-17T04:49:25Z")

</div>

Recently julia merged the basic support for riscv, which can be used as a reference:

[#system:riscv - Pull requests · JuliaLang/julia](https://github.com/JuliaLang/julia/pulls?q=sort%3Aupdated-desc+is%3Apr+riscv+label%3Asystem%3Ariscv+)

> Is someone willing to get it to build with CMake or some such build system, to make it easier to port?

Before starting actual CMake support work, I’d suggest opening an issue or posting a discussion on discourse.

julia does not currently support builds using MSVC.  
As a Windows user, I’m interested in adding support for CMake and similar cross-platform build systems.

[RFC: A transition to cmake as a build / configure system · JuliaLang/julia · Discussion #50194](https://github.com/JuliaLang/julia/discussions/50194)

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 17, 2024, 6:16am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/4 "2024-11-17T06:16:39Z")

</div>

On my SmartOS box:

```julia
[root@orshemesh ~]# pkgin se libuv
R-fs-1.6.3 Cross-platform file system operations based on 'libuv'
libuv-1.48.0 = Cross-platform asychronous I/O
lua51-luv-1.43.0.0nb1 Bare libuv bindings for Lua
lua52-luv-1.43.0.0nb1 Bare libuv bindings for Lua
lua53-luv-1.43.0.0nb1 Bare libuv bindings for Lua
lua54-luv-1.43.0.0nb1 Bare libuv bindings for Lua
py310-uvloop-0.20.0 Fast implementation of asyncio event loop on top of libuv
py311-uvloop-0.20.0 Fast implementation of asyncio event loop on top of libuv
py312-uvloop-0.20.0 Fast implementation of asyncio event loop on top of libuv

```

I develop on Linux and have compiled some of my C++ projects on Windows, using Ninja (which was a lot faster than Nmake when I first tried it) and the compiler from MSVC. I’ve used the MSVC GUI to debug programs, but I build them on the command line. I’ve also used gcc in Windows; IIRR gcc has 10-byte floats but MSVC doesn’t.

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 17, 2024, 6:31am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/5 "2024-11-17T06:31:59Z")

</div>

The discussion on GitHub mentions Meson. I have no experience with Meson, so can’t compare it with CMake, but if Meson makes cross-platform building easier, it’s fine with me. Meson depends on Python, which CMake doesn’t.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [November 17, 2024, 9:49am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/6 "2024-11-17T09:49:40Z")

</div>

> [@phma](#):
>
> Is someone willing to get it to build with CMake or some such build system, to make it easier to port?

I understand that sentiment, it is born out of the feeling “Wouldn’t **my** life be much easier if Julia used a standard build-system, like CMake or Meson”.  
I am a big fan of Meson ( and after years of fighting with CMake for LLVM a strong dislike for CMake).

But it is important to ask the question: Why do the Julia developers didn’t use CMake? In many ways we have to solve three problems:

1. Dependency management (and control). There is a tight coupling between a few dependencies (most notable LLVM and libuv) and we want to minimize the possible configuration set instead of having developers run into the same bugs multiple times, just because they don’t yet have a patch for a dependency.
2. We need to build the Julia runtime and the compiler (this would be trivial for any build-system and even with Make it’s not a big deal)
3. We need to bootstrap Julia itself, the Julia standard lib etc…

If you propose to switch the build-system to Meson or CMake you would need to answer the question: How would this make it easier for everyone developing the Julia core.

Right now as someone who just wants to work on a standard lib all I have to do is enter “make” and I get a reasonable approximation of a build that your CI system would also provide.

If you want to port Julia to a new platform the build-system really shouldn’t be the hardest part, you likely will need to turn off the BinaryBuilder provided caches, and build everything from scratch.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [November 17, 2024, 10:42am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/7 "2024-11-17T10:42:11Z")

</div>

> [@woclass](#):
>
> I’d suggest opening an issue or posting a discussion on discourse.

I don’t suggest doing that, since it has already been done multiple times and the outcome wouldn’t be much different than [the last time this has happened](https://github.com/JuliaLang/julia/issues/34356). Valentin elaborated a little bit more about the motivations.

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 18, 2024, 7:03am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/8 "2024-11-18T07:03:46Z")

</div>

I looked at the pull request and there’s a lot of files changed. Is there a list of steps to port Julia to a new platform? Try to compile, and if you get this error, do that?

How hard would it be to add powerpc64be, which I mentioned above? Powerpc64le is already available.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [November 18, 2024, 7:59am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/9 "2024-11-18T07:59:55Z")

</div>

> [@phma](#):
>
> Is there a list of steps to port Julia to a new platform? Try to compile, and if you get this error, do that?

I highly doubt that what you ask for exists.

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [November 18, 2024, 8:14am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/10 "2024-11-18T08:14:28Z")

</div>

> [@phma](#):
>
> How hard would it be to add powerpc64be, which I mentioned above? Powerpc64le is already available

Big-Endian is hard, we have no Big-Endian support so it is not just going in and porting it to a new architecture, but also going in and rooting out all the small little endian assumptions in the runtime, the language and Julia libraries.

Note that we currently don’t have an active maintainer for ppc64le and are considering dropping support for it due to the ongoing maintenance burden.

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 18, 2024, 6:46pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/11 "2024-11-18T18:46:34Z")

</div>

I want a Power box specifically to test that software that claims to work on big-endian architectures actually does.

If I get a Power box, which will take several more months, can I become the maintainer of ppc64?

---

<div class="post-metadata">

**Author:** ![vchuravy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vchuravy/32/8_2.png) [@vchuravy](https://discourse.julialang.org/u/vchuravy)\
**Post date:** [November 19, 2024, 8:51am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/12 "2024-11-19T08:51:47Z")

</div>

> [@phma](#):
>
> If I get a Power box, which will take several more months, can I become the maintainer of ppc64?

In principle, yes, but it does require profound knowledge about both Julia and PPC64. It is very unlikely that we will be able to support -BE and there is very economic incentive to do so.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 21, 2024, 6:09pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/13 "2024-11-21T18:09:09Z")

</div>

[This doesn’t not apply to “SmartOS, with its remarkable blend of the illumos kernel’s power” a fork of Solaris, even though it was BE, SmartOS only supports LE. SmartOS might though be ruled out for other reasons.]

> [@vchuravy](#):
>
> It is very unlikely that we will be able to support -BE and there is very [little] economic incentive to do so.

Not just little incentive for BE for Power8+ (NOR really for LE there), but no real incentive for any other BE arch, and supporting the first BE arch would be most difficult, though not _impossible_…

The only reason I can see for supporting BE is mainframes (and I don’t think worth it for Julia), i.e. IBM z/Architecture aka s390x (Rust does it in tier 2, but then for Linux running on the mainframe). This does not apply to Power8 [Linux], since it’s bi-endian. SPARC and AIX Linux are also big-ending, but dead.

We will likely never support z/OS (even if it and its hardware would change to bi or little endian); and running Linux under it is neat, but I doubt very useful in the cloud era.

> [@phma](#):
>
> I want a Power box specifically to test that software that claims to work on big-endian architectures actually does.

Why don’t you just run that software on LE (POWER) Linux?

Intriguingly IBM’s [Endianness Guidance for Open-Source Projects](https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/javier-perez1/2021/01/19/endianness-guidance-for-open-source-projects?communityKey=64d1d1bd-66bc-4ecb-b9e8-0372b18c5bcb) [for targeting s390x] doesn’t even mention their POWER arch under either the big- or little- endian example architectures.

[https://www.reddit.com/r/mainframe/comments/4exnxy/zarchitecture\_and\_power\_architecture/](https://www.reddit.com/r/mainframe/comments/4exnxy/zarchitecture_and_power_architecture/)

> I’ve always felt the strength of the z architecture is plainly demonstrated in use of z/OS …  
> When using a z machine as a Linux server farm, those benefits are far harder to quantify.

I.e. this is ruled out, seemingly forever: [IBM LinuxONE](https://www.ibm.com/linuxone)

> IBM LinuxONE is an enterprise-grade Linux® server, powered by the [IBM Telum®](https://www.ibm.com/linuxone/telum) processor

> <https://stackoverflow.com/questions/55963736/switching-endianness-on-arm>

> No processor **needs** to be run in big or little endianness. The reason for that is simple: anything you can do in one mode, you can also do in the other. …
> 
> In ARM it seems that this instruction is called the `rev` instruction. Let me [quote Peter Harris](https://community.arm.com/support-forums/f/architectures-and-processors-forum/4901/how-to-set-endianness-in-arm-cortex-a8/26783#26783), a Mali GPU distinguished engineer at Arm:

[https://community.arm.com/support-forums/f/architectures-and-processors-forum/4901/how-to-set-endianness-in-arm-cortex-a8/26783#26783](https://community.arm.com/support-forums/f/architectures-and-processors-forum/4901/how-to-set-endianness-in-arm-cortex-a8/26783#26783)

> > I need to run big endian code but i don’t know how to set endian option in cp15 registers could any suggest me how to set EE bit set

> It’s a very expensive way of doing it. If you are going to do functions to load single fields from memory then just use little-endian loads and use the “rev” instruction to reverse the result - it’s only one additional instruction and much faster …

> **[Is ARM big endian or little endian?](https://www.quora.com/Is-ARM-big-endian-or-little-endian/answer/Joe-Zbiciak)**
>
> Answer (1 of 8): Just adding a tidbit to the generally correct answers already. Original ARM was little-endian, and nearly every use today is also, even though support for big-endian was added fairly early. The downside, as some have noted, is that...

> ARM cores support both modes, but are most commonly used in, and typically default to little-endian mode. Most Linux distributions for ARM tend to be little-endian only. The x86 architecture is little-endian. …  
> Modern ARM processors support a big-endian format known architecturally as BE-8 that is only applied to the data memory system. Older ARM processors used a different format known as BE-32 that applied to both instructions and data. BE-8 corresponds to what most other computer architectures call big-endian.

[https://github.com/flightlessmago/MangoHud/issues/1330#issuecomment-2124336674](https://github.com/flightlessmago/MangoHud/issues/1330#issuecomment-2124336674)

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 22, 2024, 12:14pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/14 "2024-11-22T12:14:22Z")

</div>

> [@Palli](#):
>
> Why don’t you just run that software on LE (POWER) Linux?

Because that wouldn’t test big-endian portability, it would test only that it runs on Power, including that it works with 128-bit floats. (The only place 128-bit vs. 80-bit float makes any difference is in the test of the Euler spiral.)

Convertgeoid, one of the Bezitopo programs, reads and writes geoid files in various formats. One of them, NGS, is available in both big-endian and little-endian versions. The government agency that publishes it says that Unix is big-endian and Windows is little-endian. There are many little-endian Unices. I’ve tested convertgeoid on big- and little-endian _files_, but not on big-endian _hardware_.

PerfectTIN, which shares some code with Bezitopo, uses the Plytapus library, which I took over and renamed from a French Canadian, to read and write PLY files. PLY binary files can be big- or little-endian. Again, I’ve tested it on big-endian and little-endian files, but not on big-endian hardware.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [November 22, 2024, 12:50pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/15 "2024-11-22T12:50:52Z")

</div>

> [@phma](#):
>
> The government agency that publishes it says that Unix is big-endian and Windows is little-endian.

That’s misinformed. I think you have a dream, and I want to kill that big-endian dream. 🙂 And tell you why. Which BE Unix do you think is important and why? I’m just questioning that, why not just use a LE Unix/Linux?

> [@phma](#):
>
> Because that wouldn’t test big-endian portability,

Testing can only show presence of bugs, never absence of bugs. Even if you could fix such bugs (and support 128-bit floats), in Julia, even with some _formal_ proof… you wouldn’t fix the potential bugs in the Julia _package_ ecosystem. I think it’s just not worthwhile to even try. Note, in Java this might be easier, even already done (like for sandboxed Java, it also can call C, just less done with JNI, then has same problem). But in Julia you have `ccall` and it seems to me if you can call C or Rust or whatever, then such code would have to be compiled for BE too, i.e. you duplicate all JLLs for at least the POWER platform, LE plus BE, assuming you have LE already, and I’m not even sure LE there is well supported in JLLs.

E.g. “big endian”, seemingly, format from 2023:

> **[qoa-specification.pdf](https://qoaformat.org/qoa-specification.pdf)**
>
> 24.22 KB

Also in the OK image format:

> <https://github.com/phoboslab/qoi/pull/6#issuecomment-979545171>
>
> \> Addressed in 81b438c
> 
> Well, this addressed endianness, and changed some of t…he lines that the PR also changed (so that the PR no longer applies). I filed #21 to discuss the points from https://github.com/phoboslab/qoi/pull/6#issuecomment-978787732 above.

> [@phma](#):
>
> PLY binary files can be big- or little-endian. Again, I’ve tested it on big-endian and little-endian files, but not on big-endian hardware.

It’s worthwhile to support all file formats with Julia, on little-endian _hardware_. Many formats are big-endian, aka network order, for historical reasons, with little-endian hardware now more common, I’m confused why LE isn’t used like for QOA, Quite OK Audio (and other Image) format, I mentioned above (QOA needs to be wrapped for Julia, while QOI has already been with [QOI.jl/test/runtests.jl at 76aab3535ed1ba05c711f6005344d5ef58ac6330 · KristofferC/QOI.jl · GitHub](https://github.com/KristofferC/QOI.jl/blob/76aab3535ed1ba05c711f6005344d5ef58ac6330/test/runtests.jl#L73). All formats, big or little, can be supported in Julia, I suppose the formats you mention store in the header which is used; or not as with Photoshop if I recall, it saved in big-endian on then/classic MacOS, but in little-endian on Windows. Meaning the files couldn’t be opened on Windows and vice versa (or at least without taking it into account). It must be a solved problem by now, somehow. Note all current macOS hardware, for decades now, is little-endian.

---

<div class="post-metadata">

**Author:** ![phma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/phma/32/6576_2.png) [@phma](https://discourse.julialang.org/u/phma)\
**Post date:** [November 22, 2024, 9:00pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/16 "2024-11-22T21:00:14Z")

</div>

So inform them. I doubt you’ll get an answer. I told them that the Alaska file and the Lower 48 file disagree at Kitimat. Never got an answer.

The build scripts of Bezitopo and PerfectTIN, which are in CMake, have endianness tests, and the code refers to the result of those tests. Those tests aren’t tested with full coverage without running on big-endian hardware.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [November 23, 2024, 10:41am UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/17 "2024-11-23T10:41:57Z")

</div>

> [@phma](#):
>
> I want a Power box specifically to test that software that claims to work on big-endian architectures actually does.

I sympathize, however the Julia world assumes little-endian is the only endianness. I hope there’s no resurgence of big-endian hardware in the future…

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [February 17, 2025, 8:59pm UTC](https://discourse.julialang.org/t/porting-julia-to-new-platforms/122698/18 "2025-02-17T20:59:57Z")

</div>

> [@phma](#):
>
> I want a Power box specifically to test that software that claims to work on big-endian architectures actually does.

Another big-endian architecture is IBM’s s390x. I believe it’s more relevant than PowerPC, given that IBM’s mainframes run on it. There’s an issue on Julia’s issue tracker for an s390x port, and someone recently expressed interest on Slack on working on the issue:

- [Support s390x · Issue #29637 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/29637)
- [Slack](https://julialang.slack.com/archives/C67910KEH/p1739776722707999)