Add GitHub workflow for cross-compilation and fix build issues for macOS and FreeBSD#636
Add GitHub workflow for cross-compilation and fix build issues for macOS and FreeBSD#636slp merged 11 commits intocontainers:mainfrom
Conversation
There was a problem hiding this comment.
The runner configuration lets me run unit tests from VS Code editor.
cfae6d8 to
b5dc66c
Compare
| name: Cross-compilation (macOS) | ||
| runs-on: macos-latest | ||
| env: | ||
| DYLD_LIBRARY_PATH: /Library/Developer/CommandLineTools/usr/lib/ |
There was a problem hiding this comment.
@slp I had issues building the macOS version which looked like this:
slp/homebrew-krun#14
Setting DYLD_LIBRARY_PATH fixed it for the GitHub action. Maybe the krun_display patch for homebrew is not needed.
02a1a18 to
40f295f
Compare
|
Please try to make sure the commit messages do what the title and commit msg text says. Like
|
|
@mtjhrc Split commits and improved messages. |
|
There are still You should probably also disable these failing tests:
|
|
@mtjhrc Yeah, currently I have Sorry, I think I actually only tried to run |
|
I'd suggest we also add |
|
As for those two particular Claude suggests some assertions in those tests are correct on Linux but not macOS. IMHO if the primary goal here was to fix the build, we could address this properly in another PR. I already feel I should have made my PR more focused in the first place. |
|
/gemini review |
9a5926e to
17149c3
Compare
Huge thanks though! The macOS unit tests have been completely unusable, this gives us an opportunity to properly start maintaining them.
Looks fine for now - the sematics of the emulated EventFd are kind of broken but the actual non-test code is smart enough to avoid the problems, I plan to look into refactoring EventFd stuff in libkrun 2.0 so there's a separate explicit read and write end.
Yes this fine and generally recommended when using libkrun - we consume a lot of file descriptors. Btw by default macOS gives you a lower limit over SSH (256 fds) than e.g. if you open a terminal in the GUI... |
No problem! This project is fun. :) |
|
Example of successful cross-compilation workflow runs: |
|
Ok, I think it's done. Any other thoughts @mtjhrc? :) |
Signed-off-by: Jan Noha <nohajc@gmail.com>
Signed-off-by: Jan Noha <nohajc@gmail.com>
- fixed broken init rule - fixed FreeBSD base image URL for x86_64 and arm64 Signed-off-by: Jan Noha <nohajc@gmail.com>
- removed parts of tests which prevented `cargo test` from compiling - added `config.toml` which codesigns unit tests when executing `cargo test` - `tests/run.sh` and `.cargo/macos-test-runner.sh` share the same entitlements plist Signed-off-by: Jan Noha <nohajc@gmail.com>
- linkage should be established in the vmm create instead of libkrun Signed-off-by: Jan Noha <nohajc@gmail.com>
- cargo tests for this crate were incorrectly enabled on macOS Signed-off-by: Jan Noha <nohajc@gmail.com>
Signed-off-by: Jan Noha <nohajc@gmail.com>
- linker flag moved to the end of the command Signed-off-by: Jan Noha <nohajc@gmail.com>
The macOS EventFd is pipe-backed, and as_raw_fd() returns the read end. EventSet::OUT (EVFILT_WRITE) on a read-only pipe fd never fires on kqueue. Changes made to event_manager.rs: - Switched DummySubscriber from EventSet::OUT to EventSet::IN throughout (interest_list, register_ev2, event handling) - Pre-write data to eventfds before run() so IN events fire immediately - Replaced processed_ev1_out/processed_ev2_out with processed_ev1_in/processed_ev2_in - test_modify still exercises the EventManager::modify() code path and error case, but no longer tests OUT→IN transition (which requires Linux-only eventfd semantics) - The test_unregister test takes ~3s due to a separate issue: the macOS Epoll::wait() ignores the timeout parameter and hardcodes a 3-second timeout. Signed-off-by: Jan Noha <nohajc@gmail.com>
Signed-off-by: Jan Noha <nohajc@gmail.com>
- the implementation is currently Linux-specific Signed-off-by: Jan Noha <nohajc@gmail.com>
mtjhrc
left a comment
There was a problem hiding this comment.
LGTM, this is great, fixing the unit tests on macOS has been long overdue, thanks!
|
Some of them which don't require starting a VM could be even run in CI. |
I figured it would be a good idea to run automated builds for our cross-compilation scenarios. So the new pull request workflow tests the following combinations:
Of course I immediately found out my newly merged FreeBSD init port didn't compile, so the fix is included (it was just a broken Makefile rule).
I also tried to fix various issues with building unit tests on macOS which popped up in my VS Code. Most of the changes were suggested by AI with the following explanation: