Ubuntu PPA

[staticfloat]

EDIT: For the impatient ones, Skip down to my comment below with directions on how to install all dependencies for Julia on Ubuntu 12.04.

It'd be great to have an Ubuntu PPA that collects all the software that Julia needs to compile. This could significantly cut down on compile times, and would be a nice first step toward having actual binary packages of Julia for debian.

From my tests, the following packages work with/are necessary to build Julia:

gfortran
llvm-3.1-dev (ppa:dr-graef/llvm-3.1.precise)
libblas-dev
liblapack-dev
libarpack2
libpcre3-dev
libglpk-dev
lighttpd
libgmp-dev
libunwind7-dev
libreadline-dev

This leaves SuiteSparse (Only 3.4.0 is available, no 4.0.2, as far as I can see), FFTW (Installing libfftw3-dev didn't work for me; I got the dreaded LoadError, so I figured I'd just let Julia compile her own which works), zlib (It doesn't come with large file support by default), and whatever else I'm missing.

[ViralBShah]

There is very little difference from SuiteSparse 3.4.0 to SuiteSparse 4.0.2. Does it not just work with 3.4.0?

[dmbates]

libblas-dev depends on the libblas3 which is the package for the reference blas. Installing reference blas and reference lapack will result in slower linear algebra code that installing OpenBLAS or Atlas. There is a libopenblas-dev package but the current version is 0.1.1 whereas the version specified in julia/deps/Versions.make is 0.2.4. I don't know why the Ubuntu version is so old - there may be problems with the license for later versions.

Similarly, libpcre3-dev on Ubuntu 12.10 is version 8.30 whereas Version.deps asks for 8.31. I'm not sure if that is important. For libglpk-dev version 4.45 is available but 4.47 is requested.. For libarpack2-dev version 3.1.1 is available and 3.1.2 is requested. ...

Viral has already suggested that an earlier SuiteSparse may be acceptable. It would be good to determine which available Ubuntu/Debian packages are acceptable for compiling Julia. When the currently released version is not acceptable it may be possible to get the source package and upgrade it.

For example, the sources for the debian subdirectory of suitesparse packages are maintained in a git repository at http://anonscm.debian.org/git/pkg-scicomp/suitesparse.git/ but they haven't been updated in 2 years.

[staticfloat]

@ViralBShah: SuiteSparse 3.4.0 from the ubuntu repository does not work for me. When just running make (Because I forget to first run repackage_system_suitesparse3.make) I get the following error:

SuiteSparse_wrapper.c:109:25: error: use of undeclared identifier 'SuiteSparse_long'
        isize =  sizeof(SuiteSparse_long); break;
                        ^
SuiteSparse_wrapper.c:118:9: error: use of undeclared identifier 'SuiteSparse_long'
        SuiteSparse_long *spt = (SuiteSparse_long *) cs->p;
        ^

Which does on for a while, but I think you get the gist. Even when I run repackage_system_suitesparse3.make first, (even though I don't believe it would fix the above error) I get the following:

/usr/bin/ld: libamd.a(amd_i_control.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
libamd.a(amd_i_control.o): could not read symbols: Bad value
collect2: ld returned 1 exit status

I'm not entirely sure what this error is about, though.

@dmbates: I'm not sure how to go about creating deb's. Never done it before, although I am looking into it.

[staticfloat]

Because OpenBLAS has such a finely-grained hardware compilation process (e.g. it specializes on CPU architecture) I'm not sure dpkg has methods for choosing the proper deb for any given computer. I just compiled a .deb of OpenBLAS 0.2.4, but it's specialized for my processor.

[ViralBShah]

As @staticfloat said, some of these will not "just work", but it should be easy to make them work. I cannot imagine us depending on new features of any of these. The exceptions are openblas, which is old, and also that we compile lapack into it with the openblas patches. At some point, perhaps debian/ubuntu can have an openblas package that provides the lapack dependency as well - but I think we will have to take it up with the Debian Science Maintainers.

The other one is Rmath, where we have patched it to use julia's librandom (basically dsfmt+randmtzig). For the rest, we should be able to use existing debian/ubuntu packages with some small modifications.

[ViralBShah]

@staticfloat if you build openblas with DYNAMIC_ARCH=1, it should build for all the cpu types it knows about. The julia make install does this, and you end up with a libopenblas that is twice as large.

[dmbates]

I have successfully built and tested Julia under Ubuntu 12.10 amd64 with the flags

USE_SYSTEM_LLVM=1 USE_SYSTEM_READLINE=1 USE_SYSTEM_ZLIB=1 USE_SYSTEM_ARPACK=1 USE_SYSTEM_FFTW=1 USE_SYSTEM_PCRE=1 USE_SYSTEM_GMP=1 USE_SYSTEM_LIBUNWIND=1 USE_SYSTEM_LIGHTTPD=1

I did remove the contents of the julia/usr/lib directory before checking that Julia would pass testall with these system libraries. This cuts down on the number of libraries in julia/usr/lib but of course the biggest gains could be realized by getting system packages of openblas and suitesparse.

May I suggest that the USE_DEBIAN stanza in julia/Make.inc be replaced with only these flags and possibly renamed to USE_UBUNTU_12.10 or something like that.

Also, I think it would be a good idea to change to

OPENBLAS_VER = v0.2.4
LAPACK_VER = 3.4.2

in julia/deps/Versions.make

Both of these versions have been out for some time and it would be good to keep current.

[staticfloat]

@dmbates: Great, that's exactly what I've experienced with the exception of LLVM on 12.04. (I had to use a third-party backport to 12.04 to get it)

Also, I've been using Homebrew for so long, I had no idea that Julia natively built those OpenBLAS and LAPACK versions! I'll go open a pull request.

[staticfloat]

And I am delirious, and did not remember that OpenBLAS 0.2.4 is the one I tested and didn't work because of this bug.

[staticfloat]

I've started a "Julia Dependencies" PPA, but I'm still ironing out some issues. LLVM 3.1 and FFTW should pretty much work as I simply backported them from Quantal (Ubuntu 12.10).

[svillemot]

Hi,

I am a Debian Developer, and I am interested in getting Julia into Debian (and therefore into Ubuntu).

Before this can happen, some work is needed on dependencies. AFAICT, here are the dependencies that are not yet packaged in Debian:

• SuiteSparse 4.0.2 (should happen soon, 4.0.2 is already committed in Git)
• double-conversion
• openlibm
• libuv
• amos (though we may decide to not use an independent package and reuse the files in julia's tree)
• random/dsfmt

OpenBLAS is indeed at version 0.1.1 in unstable (0.2.4 in experimental), but this is not an issue. FFTW and zlib seems to work fine, unless I am missing something. LLVM 3.1 works fine as long as you set LLVM_CONFIG=llvm-config-3.1 on the command line.

I don't know exactly when I will be able to do this packaging work. Of course, any help is welcome. In particular, I am willing to sponsor uploads into Debian.

[staticfloat]

Great to hear, Sébastien! As I pointed out above, I've started putting together an Ubuntu PPA, but as this is my first time packaging software for Ubuntu, I'm certain I've done a rather shoddy job (For instance, I haven't been packaging SuiteSparse or OpenBLAS as libraries, but rather as a single binary!). Someone with your experience will help a lot in this regard.

I believe the reason zlib wasn't working for me was that zlib must be compiled with large file support which the 32 bit version available in Ubuntu is not, but the 64-bit version is. (And by 32 vs. 64-bit versions, I am referring to lib32z vs. lib64z)

I'm still not certain why the FFTW available in 12.04 didn't work. It's only a few versions behind, but Julia didn't want to link with it. Backporting the 12.10 version worked, however, and it's of the version we want (>= 3.3).

[nolta]

We need FFTW 3.3.2 because of this fix (from the release notes):

Make libfftw{threads,mpi} depend upon libfftw when using libtool; this is consistent with most other libraries and simplifies the life of various distributors of GNU/Linux.

You should be able to use an earlier version if you dlopen "libfftw3" instead of "libfftw3_threads".

[svillemot]

Here is the Intent to Package (ITP) that I opened today in Debian: http://bugs.debian.org/691912

I'll be commenting there when progress is being made.

[ViralBShah]

@sebastien-villemot - Thanks a lot for the Debian ITP. This will be incredibly useful for julia. I am happy to help in any way possible to get julia accepted into debian.

I also notice that you are one of the Dynare developers. It would be interesting to hear on views on dynare and julia at some point.

[kmsquire]

@staticfloat or @sebastien-villemot (or anyone), can you tell me if the 32-bit zlib library that comes with Debian contains the gz_64 functions (gzopen64, gzread64, etc) and z_off64_t? The way zlib is currently built in julia, the gz_ functions are aliases for gz_64 functions. This could be changed so that julia calls the gz_64 functions directly, I think, as long as z_off64_t is available. (Not all of the gz* functions have 64 bit equivalents, so this might reduce functionality and take some minor rewriting to get working.). An alternative is not to support large gzipped files on 32-bit systems (even though other large files would be supported).

[svillemot]

@kmsquire The answer seems to be yes:

(sid-i386)sebastien@brouzouf:~$ nm /usr/lib/i386-linux-gnu/libz.a |egrep 'gz.*64'
000009e0 T gzoffset64
000003f0 T gzopen64
000005c0 T gzseek64
000008f0 T gztell64

[kmsquire]

Thanks! I'll work on a patch.

[staticfloat]

Alright, I've made significant progress, and I can build Julia successfully on 32-bit and 64-bit Ubuntu 12.04, with all dependencies (other than double-conversion and librandom) provided by Ubuntu. This uses the PPA I've set up to serve the build dependencies (Mostly using updated/tweaked packages from other debian releases, thanks much to @sebastien-villemot for the info that a SuiteSparse release was already in git; that was an absolute goldmine of information) and passes all tests. A quick breakdown of what this PPA contains:

• arpack-3.1.2: An updated version of arpack than what is bundled in precise, with dependencies against libblas-dev OR libopenblas-dev.
• fftw-3.3.2: An updated version of fftw - This is not completely necessary, but it was easy enough to add in.
• llvm-3.1: This is the recommended version, according to JeffBezanson, so I backported it from 12.10.
• openblas-0.2.3: This package is the one that I had to write the most from scratch, and as such has the greatest potential for gaffs, as this is my first time packaging for debian. I especially am interested in feedback on the whole "provides libblas.so.3gf" portion; it seems to work, and you can link against openblas with -lblas -llapack, but it would be great to have more experienced eyes on this. :)
• suitesparse-4.0.2: I had to manually link in libsuitesparseconfig to get the SuiteSparse_time symbol to be defined in libcholmod and libumfpack.
• zlib-1.2.7: The only difference here is that I force -D_FILE_OFFSET_BITS=64 on 32-bit systems as well, so all tests pass. No longer needed, @kmsquire changed up the zlib module to go with whatever large file support zlib happens to have.

To install on a clean Ubuntu installation, you'll need to run:

sudo add-apt-repository ppa:staticfloat/julia-deps
sudo apt-get update
sudo apt-get install $PACKAGES

Where $PACKAGES is a list consisting of:

gfortran clang llvm-3.1-dev libsuitesparse-dev libncurses5-dev zlib1g-dev libopenblas-dev libarpack2-dev libfftw3-dev libpcre3-dev libglpk-dev lighttpd libgmp-dev libunwind7-dev libreadline-dev

You can then build with the command make $BUILDOPTS where the options are:

LLVM_CONFIG=llvm-config-3.1
USECLANG=1
USE_SYSTEM_LLVM=1
USE_SYSTEM_ZLIB=1
USE_SYSTEM_SUITESPARSE=1
USE_SYSTEM_ARPACK=1
USE_SYSTEM_BLAS=1
USE_SYSTEM_FFTW=1
USE_SYSTEM_LAPACK=1
USE_SYSTEM_LIGHTTPD=1
USE_SYSTEM_GMP=1
USE_SYSTEM_PCRE=1
USE_SYSTEM_LIBUNWIND=1
USE_SYSTEM_READLINE=1
USE_SYSTEM_GLPK=1

This ties in nicely with the Travis bot I've been contributing to global warming with, as this finally allows me to build Julia on Travis without compiling anything other than Julia, dsfmt and double-conversion.

Again, I'd love comments, critiques and pointers to bring this packaging up to the standard expected of such things.

[ViralBShah]

@staticfloat This is awesome!

[ViralBShah]

We should update README.md with this. Let's have a couple of people confirm that this works. I am trying it right now.

[kmsquire]

Nice! I started working on a patch to zlib/gzip which I thought would allow julia to work with different versions of zlib and would get rid of the -D_FILE_OFFSET_BITS=64. It works fine for 1.2.7, but I can consistently make it crash for 1.2.3 (which is, e.g., in Ubuntu 12.04). I haven't had the time to debug it yet, and probably won't until next week, but it should let you remove zlib from the PPA.

[ViralBShah]

Can you also include julia as a package? That way, it would become really easy to install julia on an ubuntu machine. We could update the julia package once every often.

[staticfloat]

I can, and will, I want to make sure this stuff works before I do however,
as once you have multiple layers of dependencies, it starts to get tedious
to update things when something on the bottom needs to be updated.

On Mon, Nov 5, 2012 at 9:31 PM, Viral B. Shah [email protected]:

Can you also include julia as a package? That way, it would become really
easy to install julia on an ubuntu machine. We could update the julia
package once every often.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1451#issuecomment-10099742.

[svillemot]

On the Debian side, I have uploaded double-conversion (it is waiting for approval by FTPmasters), and I have a preliminary working julia package. Note that I had to reorganize the filesystem hierarchy in order to match Debian requirements (.jl sources in /usr/share/julia, private shared libraries in /usr/lib/ARCH/julia). I am now confident that I will be able to upload it in a couple of weeks.

[svillemot]

In order to get you a preview of the forthcoming Debian packages, I have uploaded them to: http://people.debian.org/~sebastien/julia/

These packages are installable on Debian unstable/sid amd64. They don't need any extra dependencies (except libdouble-conversion0, which is provided). I managed to compile against SuiteSparse 3.4 with a tiny patch to Julia source.

Maybe the package is directly installable on Ubuntu, I haven't checked.

[svillemot]

@staticfloat If you are interested in helping me maintaining the forthcoming Debian (and therefore Ubuntu) package, you are very welcome. This would avoid duplication of efforts. The julia package will be maintained in the Debian Science Team, and anyone can join (even non-Debian Developers).

[staticfloat]

@sebastien-villemot: Sounds great, I'd love to help. I'll take a look at your julia packages tomorrow, I look forward to learning more!

[xianyi]

Hi @staticfloat ,

I will release OpenBLAS 0.2.5 version in this week :)

Thank you

Xianyi

[dmbates]

On Ubuntu 12.10 one gets into a dependency lock when trying to install the openblas, arpack and suitesparse packages, triggered by openblas-base trying to rewrite the /etc/alternatives entry form lapack

Setting up libopenblas-base (0.2.3-1ubuntu5) ...
update-alternatives: error: alternative liblapack.so can't be slave of libblas.so.3: it is a master alternative

[dmbates]

Not sure if it would be worth it or not but one part of SuiteSparse, SuiteSparseQR, can use the Threading Building Blocks library, available as the libtbb-dev package. Currently SuiteSparseQR is not compiled with the option -DHAVE_TBB but it could be. As in many such situations it may actually make things worse to allow for multi-threading in higher level code if it conflicts with, say, a multi-threaded BLAS like OpenBlas.

[xianyi]

Hi @dmbates ,

If the application is already multi-threaded by Pthread, please try the following.

• export OPENBLAS_NUM_THREADS=1 in the environment variables.

Or

• Call openblas_set_num_threads(1) on runtime.

If the application is already multi-threaded by OpenMP, please try

• Build OpenBLAS with USE_OPENMP=1

Xianyi

[staticfloat]

@dmbates: I'm still figuring out how to setup the "master" and "slave" parts of the alternatives given in the openblas package. I'll update you when I figure out how those pieces fit together,

[staticfloat]

@dmbates: I think I may have solved the issue, and also updated libsuitesparse-dev to provide libspqr. Please let me know any issues you run into.

[kmsquire]

#1545, when merged, should allow the use of the system zlib unchanged, so it won't have to be packaged here any more.

[staticfloat]

Confirmed. Nice work, Kevin. I've removed the zlib package from my PPA.

[ViralBShah]

BTW, can this PPA be set up to be able to use winston out of the box - dependencies on cairo and such?

[ViralBShah]

I just followed the instructions here, and it was great not to build the world to get a working julia. The only things that get built now are openlibm, double-conversion, random, and Rmath.

[ViralBShah]

I get a segfault doing any BLAS operation with this openblas. I presume that the openblas is built for all architectures. It is more likely that VirtualBox (4.2) is not liking some SandyBridge instructions.

[xianyi]

Hi @ViralBShah ,

I think I fixed the SEGFAULT issue of VirtualBox on develop branch.

Xianyi

[pao]

Yes, I don't believe we've updated to an OpenBLAS that detects that VirtualBox doesn't support AVX yet because we had to skip the current release due to a bug. We should pick that up on the next OpenBLAS update.

[xianyi]

@staticfloat , Sorry for delay 0.2.5 version. Now we are trying to fix a SEGFAULT issue of dgemv.
If we finish this work, we will release 0.2.5.

[svillemot]

FYI, I requested an update of Ubuntu's OpenBLAS (which I co-maintain in
Debian). Ubuntu Raring now has 0.2.4.

[svillemot]

@ViralBShah Note that Rmath is in Debian (and Ubuntu) in the r-mathlib package, so no need to recompile it. The USE_DEBIAN flag of Make.inc should incorporate that. I will submit a patch when I merge my work on the Julia Debian package.

[svillemot]

Also, double-conversion entered Debian unstable yesterday: http://packages.qa.debian.org/d/double-conversion.html

[dmbates]

@sebastien-villemot The Rmath in Debian uses R's random number generators. The version in the deps directory has been modified to use Julia's random number generators for consistency with the rand* functions in Julia.

[svillemot]

@dmbates I see... My plan was to drop the embedded Rmath in the Debian package, but it therefore looks like I have to use the modified version. This is unfortunate because it means more code duplication in Debian. I have the same issue with the modified libuv.

[StefanKarpinski]

The libuv changes may be possible to push upstream, but the Rmath changes are unlikely to be, unless we can make it pluggable somehow, and even then my impression is that getting such a modification accepted into R is improbable. A better approach would be to replace Rmath entirely with MIT/BSD-licensed code for the same functionality.

On Nov 16, 2012, at 11:57 AM, Sébastien Villemot [email protected] wrote:

@dmbates I see... My plan was to drop the embedded Rmath in the Debian package, but it therefore looks like I have to use the modified version. This is unfortunate because it means more code duplication in Debian. I have the same issue with the modified libuv.

—
Reply to this email directly or view it on GitHub.

[ViralBShah]

I doubt the Rmath code will be easy to replace. I think we will just have to bite the bullet on keeping a modified Rmath around - whether in the main repo, or as a package going forward.

DSFMT is another piece of code not in debian. Our patched Rmath uses our patched DSFMT. All these patches are quite simple and minor, but necessary to make things build.

Perhaps we can organize all this in a way so that it is available in the upstream Rmath package, and serves multiple purposes.

[svillemot]

For the time being, the Debian package will embed modified copies of Rmath, DSFMT and libuv. I understand that for Rmath and DSFMT, this is likely to remain like that. For libuv, if you could push your changes upstream, that would be great. I got in touch with the nodejs maintainer in Debian, and we agreed to create a separate libuv package once nodejs stabilizes the API, so that julia and nodejs depend on that separate libuv package.

[ViralBShah]

@loladiro @vtjnash You guys have been talking to the libuv upstream. Anything to add here?

[Keno]

I/O is such a fundamental component of any programming language that we need the flexibility to modify libuv in order to be usable by Julia and we need to be able to do so even if the proposed change is not on the priority list for joyent (e.g. joyent/libuv#451). That said I would love to use stock libuv and will make every effort to reintegrate our changes into their master (once all the work is done for Julia, so we know what we need), but I would not compromise on Julia's performance or features, for the sole purpose of making it work with stock libuv (that is also the reason libuv is one of the few libraries we link statically). Once the Julia I/O layer is done and libuv is stable, this can be reevaluated, but for now, being able to keep a separate version is absolutely essential.

[ViralBShah]

Can we close this?

[staticfloat]

Yes, we can close this. I think we should document it somewhere though.

[toddleo]

@staticfloat Hi Elliot, I noticed that the Julia Nightlies PPA is out-dated(the last build was about a week ago). Will this PPA keep rolling in the near future? Thanks for your effort!

[staticfloat]

Yep! Its blocked by 32-bit test failures. We've got a fix in the pipeline,
so you should be getting new builds by the weekend.

On Thu, Jan 29, 2015, 18:44 Todd Leo [email protected] wrote:

@staticfloat https://github.com/staticfloat Hi Elliot, I noticed that
the Julia Nightlies PPA
https://launchpad.net/%7Estaticfloat/+archive/ubuntu/julianightlies is
out-dated(the last build was about a week ago). Will this PPA keep rolling
in the near future? Thanks for your effort!

—
Reply to this email directly or view it on GitHub
#1451 (comment).