LLVM SDK extension arm target support

Hi, I have mostly finished my first adwaita application and I am trying to figure out how to build it with flatpak.

The app is written in Zig, and I need to use a patched fork of the Zig compiler due to this issue. The flatpak build fails because the org.freedesktop.Sdk.Extension.llvm18 extension apparently does not have the arm target:

CMake Error at cmake/Findllvm.cmake:30 (message):
  LLVM (according to /usr/lib/sdk/llvm18/bin/llvm-config) is missing target
  ARM.  Zig requires LLVM to be built with all default targets enabled.
Call Stack (most recent call first):
  CMakeLists.txt:140 (find_package)

How can I get full llvm for my build? I obviously can’t build it as that takes a very long time. I also can’t yet build the patched compiler ahead of time as I only “fixed” mac arm linux by breaking arm linux, so it’s going to change still.

So far this is my configuration file:

id: com.github.TeamPuzel.Crates
runtime: org.gnome.Platform
runtime-version: '46'
sdk: org.gnome.Sdk
command: crates

  - --socket=wayland
  - --share=ipc
  - --socket=fallback-x11
  - --share=network

  - org.freedesktop.Sdk.Extension.llvm18

  - name: crates
    buildsystem: simple
      # Custom Zig
      - cd src/zig; mkdir build; cd build; cmake .. -DCMAKE_PREFIX_PATH="/usr/lib/sdk/llvm18;/usr/lib/sdk/llvm18/lib"; make install
      # TODO: Copy the lib folder to the install directory
      # Application
      # TODO: Use the correct path to the built zig
      - cd src/crates zig build -Dversion="1.0.0" -Dstable -Doptimize=ReleaseSmall
      - type: git
        url: https://github.com/TeamPuzel/zig.git
        branch: master
        dest: src/zig
      - type: git
        url: https://github.com/TeamPuzel/Crates.git
        # tag: 1.0.0 stable
        branch: main
        dest: src/crates

the readme for the llvm sdk indicate what you to do. And you didn’t

Hint: it has to do with setting path so it can actually find it.

Also we don’t support arm. Only aarch64.

Why would I need to add the path if I’m passing it to cmake anyway. The build process is fine with not having these in the path, and the error message states that it did find llvm, just that it has some of the default targets disabled. Adding the paths doesn’t change the output.

I did not say anything about targeting arm, only the llvm missing the target. That’s just a requirement of building the compiler, all targets have to be present. I suppose I just have to build llvm as well, which is a significant waste of time.

Then disable the target. Build anything but the two supported is useless. And that’s why we don’t build them.

Also CMAKE_PREFIX_PATH isn’t how you set the path. It’s just a fluke it seems to work.

No, I am following the Zig documentation Building Zig From Source · ziglang/zig Wiki · GitHub, this is in fact how you set these paths when building the Zig compiler.

If your intention is to be pedantic and correct me on non issues instead of addressing the problems I described, I would have you know that you can just ignore this post. You don’t have to help if you don’t want to :slight_smile:

Considering I have no intention of having dependencies other than libadwaita I can easily cross compile. It would be much easier to just make binary releases on GitHub and download the binaries instead of building them for the flatpak. What is the benefit to building the program in the flatpak?

It is adding so much complexity; to do this properly I would have to maintain not just a reproducible way to build my program but also the zig compiler. It’s a lot of infrastructure for no benefit.

And you just can’t use the ziglang extension?

No, that extension is not useful, it’s a release behind.

Zig is still a new, unstable language and changes really fast, an older version is unlikely to compile code written in newer Zig. There’s often breaking changes even in between releases.

Zig also currently hardcodes too small of a minimum page size for aarch64-linux which prevents running precompiled Zig on Apple hardware. I’m not familiar with flatpak so I don’t know if it prevents this issue, but even if it does I still need the latest compiler.

This is fine though, I can just cross compile the binaries and the flatpak can install them from a github release: Crates/build.zig at 7ce851f432707fd96f1ccb24834e00af1cafddd7 · TeamPuzel/Crates · GitHub

You can help testing that new version here Update 2 modules by flathubbot · Pull Request #25 · flathub/org.freedesktop.Sdk.Extension.ziglang · GitHub

If the build is already gone comment with bot, build

I can try building with it, I think my build of zig should be close enough to 0.13.0

How can I use this test version in my .yml file?

Still, whether I use precompiled binaries or the 0.13.0 toolchain, I will also have the added complexity of OpenGL not working and the app running very slowly. It seems that I would have to set up even more steps to actually get the asahi mesa extension when building for that platform, and distribute the app separately for it.

It’s really easy to accidentally install the wrong version from the store, it seems to sometimes default to the standard version even if an asahi build exists. If I didn’t try building my own application I don’t know if I would have figured out why half my apps were slow and unresponsive.

I like the idea of sandboxed apps that I can conveniently download from a store and see what permissions they have. Why does that app have to be less portable? Is there a more correct way to bundle a gnome application?

Having my build system be more complicated than the program itself feels misguided. The selling point of Zig is how easy it is to make static, portable programs; applying this much CI to a Zig program is like putting pineapple on pizza.