I haven't had a chance to look into this. Inline assembly is failing: CC src/sys.o sys.c: In function ‘jl_cpuid’: sys.c:425:5: error: impossible constraint in ‘asm’ make[2]: *** [sys.o] Error 1 make[1]: *** [julia-release] Error 2 make: *** [release] Error 2
_Chris On Friday, April 25, 2014 11:20:43 PM UTC-4, Viral Shah wrote: > > Please do share logs. > > -viral > On 26-Apr-2014 8:23 am, "Christopher Fusting" > <[email protected]<javascript:>> > wrote: > >> Any progress on this? Trying to build Julia on a beaglebone black. >> Would be happy to share the logs. >> >> _Chris >> >> On Friday, November 1, 2013 4:21:03 AM UTC-4, Viral Shah wrote: >>> >>> For 0.3, we are going to try migrating to MCJIT. LLVM is likely to have >>> multi-module support in the 3.4 release - which should make it possible for >>> us to use MCJIT, which should pave the way for ARM support. >>> >>> Basically, we will get the 0.2 release done, the LLVM 3.4 release should >>> happen in a few weeks. If everything works out well and optimistically, we >>> could be experimenting with this quite soon. Keno probably has some early >>> work on MCJIT migration already. >>> >>> Also, openblas is going to have an ARM port in the release after next - >>> which will be very nice, though not essential. >>> >>> -viral >>> >>> >>> >>> On 31-Oct-2013, at 10:18 pm, Arnaud Amzallag <[email protected]> >>> wrote: >>> >>> > Hello to all the Julia developers; >>> > >>> > first thumbs up for this great language. I love the syntax, not >>> verbose and flexible, and it makes sense. I wrote for years in Matlab and >>> switched to R a few years ago. I wrote C++ when I needed speed where I >>> could not vectorize my code. I was very attracted by the potential of >>> having a fast code and not vectorizing, and I picked up the language pretty >>> fast. >>> > >>> > Apart from my job, I was a robotic hobbyist at some point, I am >>> considering playing with the Raspberry pi (Hoppy). It could make a lot of >>> sense to have julia embedded in a robot. Often, amateur robotics projects >>> rely on C compiled for Atmel processors (a few years ago at least it was >>> the case), and it is quite cumbersome to program in C when experimenting. >>> Julia seems great for experimenting with robots (for instance running on >>> Debian for Raspberry Pi) because it is a high level language, and at the >>> same time it seems very efficient. I saw discussions about having Julia >>> running on a linux for ARM; >>> > >>> > I wonder if there was some progress on getting Julia to work on an ARM >>> processor. >>> > >>> > Best regards, >>> > >>> > Arnaud >>> > >>> > On Thursday, May 16, 2013 11:21:24 PM UTC-4, Viral Shah wrote: >>> > See: https://github.com/JuliaLang/julia/issues/3134 >>> > >>> > -viral >>> > >>> > >>> > >>> > On 16-May-2013, at 10:20 PM, Stefan Karpinski <[email protected]> >>> wrote: >>> > >>> > > Perhaps we should make an "up for grabs" issue to track/encourage >>> this port? >>> > > >>> > > >>> > > On Thu, May 16, 2013 at 12:40 PM, Viral Shah <[email protected]> >>> wrote: >>> > > The first step would be to get a minimal julia running on ARM. I am >>> not sure if the debian armhf architecture is supported by LLVM's ARM >>> support. Here is the build log: >>> > > >>> > > https://buildd.debian.org/status/fetch.php?pkg=julia&; >>> arch=armhf&ver=0.1.2%2Bdfsg-3&stamp=1368675598 >>> > > >>> > > The julia system image build fails with: >>> > > LLVM ERROR: Not supported instr: BMOVPCRX_CALL %R3<kill>, <regmask>, >>> %LR<imp-def,dead>, %SP<imp-use>, %R0<imp-use,kill>, %R1<imp-use,kill>, >>> %R2<imp-use,kill>, %SP<imp-def>, %R0<imp-def>; dbg:no file:0 >>> > > >>> > > If the debian ARM build can be made to work, it will at least become >>> a supported architecture and the rest will follow. >>> > > >>> > > -viral >>> > > >>> > > >>> > > >>> > > On 16-May-2013, at 9:40 PM, Stefan Karpinski <[email protected]> >>> wrote: >>> > > >>> > > > Not necessarily. There are two possible versions. One where the >>> whole LLVM infrastructure is included in the runtime and the program can >>> and does JIT new code as needed while running. Then there's a version that >>> tries to pre-generate all code that might be needed and doesn't include any >>> LLVM infrastructure. That would either require being able to prove that all >>> possible code has been generated already, which is generally quite hard and >>> would require feedback from the compiler, or it would have the possibility >>> of failing execution. We will almost certainly have the version that >>> includes LLVM first and then eventually have a compiler option to generate >>> binaries that don't depend on LLVM at all. >>> > > > >>> > > > >>> > > > On Thu, May 16, 2013 at 12:00 PM, Lewis Girod < >>> [email protected]> wrote: >>> > > > Thanks, that is useful information. >>> > > > Would the forthcoming static compiler remove the dependency on >>> LLVM? >>> > > > >>> > > > >>> > > > On Thu, May 16, 2013 at 11:39 AM, Stefan Karpinski < >>> [email protected]> wrote: >>> > > > h2j.c is an experiment I wrote using libclang to parse C header >>> files and generate Julia bindings for that code. It should probably be >>> retired since I'm pretty sure it is fully superseded by things like >>> Clang.jl and Cpp.jl. The Julia JIT does, however, use LLVM for code gen >>> (see src/codegen.cpp), so it would certainly be necessary to get LLVM >>> working on ARM, which is probably quite nontrivial. I have no idea if >>> bionic vs. libc is an issue, but it certainly could be. >>> > > > >>> > > > >>> > > > On Thu, May 16, 2013 at 11:15 AM, Lewis Girod < >>> [email protected]> wrote: >>> > > > Thank you for the info. Re getting it on android, I agree it is a >>> challenge, I think mainly the issue is getting all of the dependent >>> libraries cross compiled. Does the julia JIT depend on parts of LLVM (I >>> noticed that h2j.c links in a bunch of LLVM libraries)? There may also be >>> issues relating to the fact that android uses 'bionic' in place of libc. >>> > > > >>> > > > I will file the issue - having this in the make file would make is >>> a lot easier to understand what would need to be ported. >>> > > > >>> > > > Thanks again! >>> > > > >>> > > > >>> > > > On Thu, May 16, 2013 at 10:22 AM, Viral Shah <[email protected]> >>> wrote: >>> > > > Jeff is the best person to say how far we realistically are. Even >>> when we actually have this, getting it all working on Android will be >>> another major challenge. Perhaps we can hope that julia becomes popular >>> enough at Google and someone on the Android team hacks it all up. :-) >>> > > > >>> > > > Even if you can get the basic julia distribution working on >>> Android, it will be a good start. You can use the interface in jlapi.c and >>> also look at the way the REPL works. We do not yet have a "build the >>> minimal julia" makefile option. Could you file an issue? This is not >>> difficult to do, but will require some careful work. >>> > > > >>> > > > -viral >>> > > > >>> > > > >>> > > > >>> > > > On 16-May-2013, at 7:25 PM, Lewis Girod <[email protected]> wrote: >>> > > > >>> > > > > Re. the static julia compiler - it looks like that would >>> simplify these issues a lot, because that would avoid the need to x-compile >>> llvm? >>> > > > > >>> > > > > Do you know about how far off this might be ready - just order >>> of magnitude? >>> > > > > >>> > > > > >>> > > > > >>> > > > > On Thu, May 16, 2013 at 9:10 AM, Lewis Girod <[email protected]> >>> wrote: >>> > > > > Thanks, Viral. >>> > > > > In googling around I have seen that people have been able to >>> x-compile the fortran matrix libraries for android, but it required a >>> little tweaking. >>> > > > > I'd like to play around with x-compiling the core of julia - >>> what parts are required to get the most basic functionality - the REPL I >>> guess? >>> > > > > >>> > > > > On Wednesday, May 15, 2013 9:30:41 PM UTC-4, Viral Shah wrote: >>> > > > > We have not yet had a successful ARM build. I can post the >>> debian buildd logs. I suspect that you will want the julia static compiler >>> for this, which Jeff is incrementally working towards. >>> > > > > >>> > > > > -viral >>> > > > > >>> > > > > On May 16, 2013 1:47 AM, "Lewis Girod" <[email protected]> >>> wrote: >>> > > > > I am also interested in experimenting with a stripped-down >>> installation. >>> > > > > >>> > > > > I am writing signal processing algorithms to run on an android >>> phone and I'm trying to figure out if Julia would be a good solution, as >>> opposed to writing them in C (using JNI) or Java, both of which are pretty >>> cumbersome. THe Julia language seems like what I am seeking in terms of >>> usability, but I wonder what it would take to get it running on an android. >>> > > > > >>> > > > > In particular, I would like to build a minimal Julia engine, >>> without graphics etc., that would run a single Julia program that receives >>> the next chunk of data in the stream and produces the next output. >>> > > > > >>> > > > > I would need to figure out how to keep only the relevant parts >>> of the julia system and then cross-compile it for arm. >>> > > > > Do you have any recommendations on how to go about this? In >>> particular, what components are needed for a minimal running system? >>> > > > > >>> > > > > >>> > > > > On Tuesday, April 2, 2013 2:34:46 AM UTC-4, Viral Shah wrote: >>> > > > > Most of the bulk in julia comes from the libraries. Depending on >>> your computation, you may still need to bundle these. Julia itself is only >>> a few MB, including sys.ji. >>> > > > > >>> > > > > So, what you can do for now is embed julia by using libjulia, >>> and call it the way it is called from repl-basic.c. However, you do need to >>> bundle BLAS, LAPACK, and any other libraries your code ends up using. >>> > > > > >>> > > > > Given that this is often asked, I will try to create a >>> self-contained example, and do a blog post once successful. >>> > > > > >>> > > > > -viral >>> > > > > >>> > > > > On Saturday, March 30, 2013 2:16:13 AM UTC+5:30, Velky Pivo >>> wrote: >>> > > > > The purpose is to distribute the application to the end user on >>> a flash stick, and call/execute the Scilab program residing on the stick >>> from Excel or Visual Basic on PC hard drive. >>> > > > > I do not want to open the Scilab IDE or command line to show, >>> nor I want to install full 150MB of Scilab, only the necessary support >>> package to run the scilab program file. >>> > > > > There are only calculations involved (numerical and signal >>> processing), no plots or visualization. >>> > > > > >>> > > > > On Thursday, March 28, 2013 2:08:12 PM UTC-5, Jameson wrote: >>> > > > > Yes, it is intended to be self-contained. If you set an >>> environment variable %HOME%, you can redirect all of the configuration data >>> also -- such as packages and git -- instead of using their default >>> directory %APPDATA%/julia. Note, typically, you will want to launch julia >>> through the included batch script, julia.bat. It sets up the %PATH% >>> variable for you, then passes all command line arguments through to julia >>> (so you can, e.g., pass the name of a julia script to run). >>> > > > > >>> > > > > On Mar 28, 2013, at 2:43 PM, Jacob Quinn <[email protected]> >>> wrote: >>> > > > > >>> > > > >> I can confirm the windows self-containment. I currently run >>> Julia on 2 different machines with one set of julia files sitting in a >>> dropbox folder. >>> > > > >> >>> > > > >> -Jacob >>> > > > >> >>> > > > >> On Thursday, March 28, 2013 1:40:57 PM UTC-5, Alessandro >>> Andrioni wrote: >>> > > > >> I think the Windows package is already self-contained, you'd >>> just have >>> > > > >> to set up a different HOME directory for julia and git. >>> > > > >> >>> > > > >> On 28 March 2013 15:26, Velky Pivo <[email protected]> wrote: >>> > > > >> > So, binaries are no go at present time. >>> > > > >> > >>> > > > >> > As other possibility, I would like my Julia program to be >>> placed on the >>> > > > >> > flash stick, along with the Julia runtime engine, libraries >>> and >>> > > > >> > dependencies. >>> > > > >> > I would then call the Julia runtime, which would start my >>> Julia program from >>> > > > >> > a Windows application like, for example, Excel. >>> > > > >> > >>> > > > >> > Something like : ExcelStartProcess ( >>> FlashDirectory/JuliaRuntime.EXE >>> > > > >> > --FlashDirectory/myJuliaprogram --FlashDirectory/libraries >>> etc.) >>> > > > >> > >>> > > > >> > Is this possible, and could you please direct me toward what >>> files need to >>> > > > >> > be generated and placed on the stick for this to work ? >>> > > > >> > >>> > > > >> > Thanks ! >>> > > > >> > >>> > > > >> > >>> > > > >> > >>> > > > >> > On Wednesday, March 27, 2013 3:45:28 PM UTC-5, Velky Pivo >>> wrote: >>> > > > >> >> >>> > > > >> >> I am considering compilers for scientific computing. >>> > > > >> >> I need a compiler (most lokely for Windows OS) that will >>> produce a >>> > > > >> >> standalone executable for the intel 86 and amd 64 >>> architecture (no packages, >>> > > > >> >> runtime distributables etc.). >>> > > > >> >> C/C++ is out of a question, and anything interpreted is out >>> for me as >>> > > > >> >> well. >>> > > > >> >> At the moment I am only considering Fortran. >>> > > > >> >> >>> > > > >> >> Can Julia produce standalone EXEs ? >>> > > > > >>> > > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > >>> > > >>> >>>
