-
Notifications
You must be signed in to change notification settings - Fork 3
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
go package (and others) fail to build due to cpu arch assumption (M1 Mac OSX) #36
Comments
previous ramblings about path are indeed a red herring. The base docker VM on a M1 Mac, is an arm image.
All the packages installs that install an x86/amd64 version are going to fail. I hacked build.sh for go to install the arm64 version instead, and that all seemed to work fine. |
Thanks for the report. I figured this issue would show up eventually. From a grep of
...so lots of them. It seems like everyone has their own terminology for what to call the architectures, unfortunately. BTW, we should probably set the |
@superfell please try out #38 to see if it fixes this |
With #38 I was able to successfully package go & rust, and create new cub's with them. the firefox package still fails. |
Thanks. We'll call that progress. Did you see an arch-specific failure with Firefox? The Firefox package may need X11 to pass its tests. |
Firefox is still trying x86
|
vscodium-go fails, not sure what's going on here
|
Yeah, for Firefox, its not likely to work even if it gets further. Same for vscode. Perhaps need to set arch specific filters for packages? |
Oh I see, Firefox's "Linux 64-bit" download really means x86-64, and they don't offer official ARM64 Linux builds. https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html#tier-3-targets |
This might be caused by the hostname being too long.
My machine is named |
using latest, attempting to build the go package
target/debug/cubicle package update go
results inpoking around in build.sh and in the created docker image, it looks like the build.sh assumes ~/bin is in the path, but it doesn't appear to be. At least from
docker exec -i cub-package-go sh
from that shell, it lists the path asPATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
The PATH issue may be a complete red herring, and the real issue is whatever causes the qemu logging.
I'll continue to poke around.
The text was updated successfully, but these errors were encountered: