-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
ARM nightlies #8359
Comments
I have contacted Launchpad support and got ARM builds enabled on the julia-nightlies repository. I'm certain that the first few builds will fail horribly as they will require us to create dependencies, etc.... but we'll see. ARM builds have a 4 hour build limit, and as the hardware Canonical is using as ARM buildslaves is undoubtedly less powerful than their x86 buildslaves, I wonder if we'll hit the limit. We can try though. ;) |
Can we add a customized Do you know what they are using for build slaves? If it is something like a PandaBoard ES then 4 hours might be enough. |
I wonder if it will hit 4 hours despite using all the various system libraries. The system image takes forever. |
Ok, cool - it would be good to get output from I looked around for an LLVM 3.5 PPA for ARM, but didn't find one (I guess I On Mon, Sep 15, 2014 at 2:20 PM, Elliot Saba [email protected]
|
Ah, do we need to use 3.5 instead of 3.3? Should we be using 3.5 for |
For ARM, yes. Otherwise, not yet (there is an open issue about it). On Mon, Sep 15, 2014 at 4:53 PM, Elliot Saba [email protected]
|
On making a PPA, it's way easier if you start from an existing package or PPA. Though enabling ARM builders might require special steps like Elliot had to do. I was able to tweak the MinGW package for example, and as long as you remain within the same Ubuntu version the hardest part is getting GPG keys to work with Launchpad. |
@staticfloat Is this the right place to see what's happening with the arm builds? |
Yep! That's the place. Looks like I've got some tweaking to do still. On Fri, Mar 13, 2015 at 11:01 PM, Viral B. Shah [email protected]
|
Okay, I've made some tweaks to the debian packaging rules, we'll see if we get past the dependency verification point now. |
It is now dying on the Rmath dependency. Best to let it just build that if possible. Looks like the amd64 build is also failing. Also, you have to include ARM.inc in the Make.user for things to build. Perhaps we should completely integrate the ARM build in the Makefile as there are enough people trying things out. |
With #12310 it is now possible to do Would the simplest thing to do for now be to just build them on my computer and upload them to s3? Perhaps a cross-compiled one may be the better way to go. |
@ViralBShah we could try that. Launchpad is trying to build them, but as usual, there are little problems with the build system that cause them to fail. For instance, now that we're trying to build LLVM 3.6.1 on ARM (which isn't bundled with the typical source upload package) it tries to download them and fails. If you want to experiment with doing our own arm builds, I'm totally okay with that. |
I can set up a crontab on my chromebook to upload binaries nightly - not very reliable, but will at least get us going. What should I do to upload? |
You should install the
Where the parameters can be found inside Julia as:
These should result in URLs that look similar to:
All this assuming that the architecture is actually |
I will try set this up next week. |
I see all arm builds have failed here: https://launchpad.net/~staticfloat/+archive/ubuntu/julianightlies/+packages is it (still) because of a time limit? Is there a link to a binary (any one, could be not brand new) that I've not found) or would I have too look into "the aws command line utility" (or compile myself..)? |
It's because the ARM build requires a different version of LLVM than the normal ones, and that version of LLVM isn't being bundled in the source tarball properly right now. |
I've attempted a fix here: JuliaCI/julia-buildbot@efe9f8b |
I will note that we've got some ARM builds that have made it much farther than any previous attempt right now; but they've been going for 6+ hours and aren't even done compiling LLVM. I fully expect Canonical to tell me to knock it off, especially if we attempt to build these ARM binaries with the same frequency as the non-ARM binaries (e.g. every day). It may be the case that we really do just need to make |
@staticfloat Couldn't you build LLVM as a separate package so that you don't need to do that everyday? |
Tarballs are always preferable. Also, you could try using the stock llvm 3.6.1 binaries if they have those for the ppa. |
I am wondering if we should bother with PPAs in general, given that they always end up using dependent libraries that have known bugs, which are fixed in the tarballs. |
Well, packages are the way Linux users expect to get their software, and they offer automated updates which would be relatively painful to do manually when you don't follow Julia's development very closely. (Though this doesn't really apply to ARM at this point, given that it's not completely stabilized.) |
Welp, it doesn't matter either way, since building LLVM currently fails with:
But in general, I agree with @nalimilan that distribution packages are a nice way to make Julia available. Currently, we are dodging the "old library" issue by bundling a bunch of .tar.gz files in the source .tar.gz that we upload to Canonical's buildd servers. That's not a great solution, global warming-wise, since that means we do things like build LLVM every day. If we were the ones actually building the |
We have them now: https://status.julialang.org/download/linux-arm |
Cool. Should they be listed at http://julialang.org/downloads/? |
+1 |
Added to the website in the nightlies section. Perhaps we should have a separate arm/x86 tables in there. |
It would be nice to have ARM nightlies for Ubuntu in the julianightlies PPA, if such a thing is possible. For people running on underpowered boards, this should be an easy way to get Julia rather than building it for hours.
Cc: @staticfloat
The text was updated successfully, but these errors were encountered: