Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Killed: 9 on tarm64osx #43

Closed
L-as opened this issue Dec 23, 2021 · 2 comments
Closed

Killed: 9 on tarm64osx #43

L-as opened this issue Dec 23, 2021 · 2 comments

Comments

@L-as
Copy link

L-as commented Dec 23, 2021

The code: NixOS/nixpkgs#131833

The code is essentially doing

./configure --pb ZLIB=$ZLIB LZ4=$LZ4
make tarm64osx.bootquick
./configure -m=tarm64osx
make -C tarm64osx/c

This works for tarm64le, ta6le, and (supposedly) ta6osx. Do you have any idea why this happens?

@mflatt
Copy link
Member

mflatt commented Dec 23, 2021

Since I work primarily on tarm64osx, I'm sure that things generally work there. The above sequence works for me in a fresh checkout after git submodule init and git submodule update --depth 1, except that I left off the ZLIB=$ZLIB LZ4=$LZ4 in the first line.

One things to beware is that macOS on AArch64 is picky about binaries and signing, and it keeps some sort of shadow filesystem state that can be difficult to understand. If there's any step after the ones you have above that touch the executable content, especially without unsigning it before and resigning it after, then the OS will not run it. In my initial development on macOS on AArch64, I spent a lot of time trying to understand why a valid executable failed on startup; often, it was because the binary I was trying to run had overwrriten a bad executable, and the OS had somehow flagged that path (inode?) as permanently bad until the file was explicitly deleted (and then a new file could use the same path). I still don't understand the rules, and this may not be the problem you're seeing – but I mention it because it has been a common problem in my experience, it's not obvious, and the symptom was the same killed-by-signal-9 failure.

@L-as
Copy link
Author

L-as commented Dec 23, 2021

Thanks! I'll try playing around with it myself too.

@L-as L-as closed this as completed Dec 23, 2021
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

No branches or pull requests

2 participants