Skip to content

Conversation

@chewi
Copy link
Contributor

@chewi chewi commented Jan 13, 2024

You wanted to know how to cross-compile for faster CI builds. I have prepared this as a Dockerfile for Fedora 39. This can be run with TARGETARCH=aarch64 or TARGETARCH=ppc64le. It produces an RPM. On my own machine, it takes less than 5 minutes.

I'm not suggesting you take this as-is but work it into your CI somehow. This was just an easy way for me to experiment and for you to try it out.

The CXXFLAGS and LDFLAGS variables work around some difficulty Fedora has in locating the C++ headers and libraries. Other than that though, it feels very clean, with it basically using what Fedora already provides.

Debian and Ubuntu could use a similar approach, but I think their "multiarch" support means you would normally do it differently.

chewi added 2 commits January 13, 2024 15:27
Adding `-I/usr/include/libevdev-1.0` unconditionally breaks
cross-compiling.
This can be run with `TARGETARCH=aarch64` or `TARGETARCH=ppc64le`. It
produces an RPM.
@chewi
Copy link
Contributor Author

chewi commented Jan 13, 2024

I see that your existing Dockerfiles eventually produce an image for end users. I wasn't sure whether Docker would be able to cross-compile and then produce an image for each architecture at the end, at least within a single Dockerfile, but apparently it can with some help from QEMU.

@ReenigneArcher ReenigneArcher marked this pull request as draft January 13, 2024 15:46
@ReenigneArcher ReenigneArcher mentioned this pull request Jan 14, 2024
16 tasks
@ReenigneArcher
Copy link
Member

Thanks for this!

I'm working on this in #2020.

A few notable changed from the image you submitted here:

  • the --platform is supplied in the FROM argument for the first image
  • the TARGETARCH env is determined based on the TARGETPLATFORM which can be provided from the CI workflow... I don't think there is way to dynamically set this one time, so it's set in each step that needs it... similar for the TUPLE env

I'm not getting any CMAKE_SYSTEM_PROCESSOR value though.

2.350 CMake Error at cmake/dependencies/common.cmake:51 (message):
2.350   Unsupported system processor:

It should print the value after the error. Any idea?

Besides this error it seems to be running really quickly! Only 2-3 minutes to install dependencies is a huge win already!

@chewi
Copy link
Contributor Author

chewi commented Jan 14, 2024

Yeah, I thought they might be set from CI. Hopefully you can work that out. I'm also looking at Debian/Ubuntu. I'll explain your current issue in that ticket.

chewi added 2 commits January 20, 2024 10:01
This can be run with `TARGETARCH=ar,64 TUPLE=aarch64-linux-gnu` or
`TARGETARCH=ppc64el TUPLE=powerpc64le-linux-gnu`. It produces a DEB.

Only arm64 has CUDA support enabled. NVIDIA stopped providing DEBs for
ppc64el a while back. Perhaps another approach can be taken.
Pros:
* Works for ppc64el.
* Should also work for Debian.
* Simpler build script.
* Smaller download than NVIDIA's own .run files.

Cons:
* Tied to a single toolkit version.
* Bigger download than NVIDIA's own .deb packages.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants