Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upRun Real Builds for 64-bit ARM Linux #22571
Comments
|
An update: I have been chipping away at this, slowly but surely. Once I get a patch upstreamed to bindgen, I will have a pair of Dockerfiles that build Servo for 32-bit Raspbian and 64-bit Arch Linux ARM, respectively. I do have a question, though. As a local hack, I'm currently patching the workspace's Cargo.toml in order to force all dependency crates to use the new bindgen version. How would I get several different Mozilla dependencies to all update their bindgen versions? If I don't do this, I get clang-sys linking conflicts. |
|
That would require submitting changes to the various projects to update their Cargo.toml bindgen dependency. |
Bump bindgen version This is part of improving cross compiling support for Servo. See servo/servo#22571. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/mozjs/174) <!-- Reviewable:end -->
Bump bindgen version This is part of improving cross compiling support for Servo. See servo/servo#22571.
|
@jhwgh1968 your latest change in rust-webvr make it impossible to update rust-webvr, as it requires updating so many other components. Can we backout your change and land it again once the bindgen update is ready for all the other components? |
|
I have successfully updated rust-webvr locally. I'll submit a PR. |
|
Sorry about that, @paulrouget. I was planning to open a Servo PR with the other updates right away, but I had some trouble with mozjs versions (hence the related PR that got closed) and wasn't sure about some deeper dependency changes in Cargo.lock. Thanks for your quick work, @jdm. I had to change more than that in my commit attempting this, but I presume you have the situation well in hand. I also quickly looked at the error in Travis on #23197. That's not an error message I've seen during my debugging sessions. Unless you already know what's wrong, I can poke at it some this weekend (I presume you work on Servo during regular business hours in North America). |
|
Oh, ick. I'm not sure what change in mozjs would have triggered that. |
|
Thanks for getting that fixed and merged, @jdm. That gets me quite a bit closer! |
|
After much struggle with its packages, I am finally giving up on Raspbian. I finally got to the point where I could nail down versions, and much later than I had hoped discovered Debian Stretch is still shipping GStreamer version 1.10. As mach helpfully points out, Servo requires at least 1.12, and coaxing debuilder to work in my hacked cross chroot is a bridge too far. My 64-bit build for Arch Linux is very close, but it's such a niche use case I don't see much point to upstreaming it without Raspbian. Until the Pi foundation updates their distro, I'm giving up for now. At least the experience taught me a lot, and got bindgen a missing feature! |
Servo Nightly builds for 64-bit ARM Linux (a Raspberry Pi, specifically) would be really useful to me.
I tried to build it from source in accordance with the README's advice (including building a Docker image on x86-64 containing a full cross-build environment, which was quite an adventure), but every single machine I have access to compiled 200-some-odd crates successfully... then fell victim to the infamous Script crate's memory consumption. (The Linux Kernel always tripped itself managing the swapfile, and panicked on OOM.)
While normally adding a new platform would be a lot of work, I think bors already builds exactly what I want, it just never puts the build outputs on the website with the rest. (I know that certain builds use a "fake ld" to avoid a dependency nightmare, but arm64 on linux uses real ld as far as I can tell.)
Any chance of those getting posted along with 64-bit Intel for Linux?
EDIT: correction, it does use the fake ld. Would you accept a Dockerfile or something? Because that memory requirement is quite an issue...