It seems that not all linux distributions are equally suitable for a Julia development machine. For instance, I still cannot figure out the right way of building Julia for Debian 8.11 “jessie”. The generic binaries do not work correctly with GLFW.jl (and all other OpenGL bound packages) because GLFW calls back the system’s libllvm-3.5.so instead of libllvm-6.so shipped with Julia. Building Julia with the statically linked libllvm fixes this problem, but breaks BinaryProvider.jl, because debian “jessie” does not have gfortran-7 (and gfortran-6 has an incompatible ABI).
Can anyone recommend a linux distribution where Julia works out of the box, or can be built without much tweaking Make.inc?
Though I’ve rarely tried to compile Julia, and it’s been quite a while since I messed around with OpenGL (though I remember getting it running with Ubuntu) the answer to your question is almost always Arch.
In particular, I’m fully onboard the Manjaro band wagon. In most cases it’s just wonderful. I didn’t realize what I was missing until I started using it.
I do have one brand spanking new and ridiculously overpowered laptop on which I still can’t get it working, and that’s making me very sad, but I’ll get it there eventually.
(Having said all that, if I had to take a guess, I’d say the most common configuration for Julia developers is likely to be the latest Ubuntu, so I’m surprised you find debian so quarrelsome.)
(I also just noticed that Debian is now up to 9.5: so another obvious possibility would be to just update debian.)
I’m running openSUSE LEAP, now on 15.0. Julia’s generic Linux binaries have always worked out of the box for me, and the git source code compiles without error using no special configuration.
This has been true for several years on prior Julia and openSUSE versions.
I’m on Debian stretch and I never had any problems with the generic binaries. But it’s been maybe 3 years since I last compiled Julia from scratch, I think I was on Debian then as well…
Interesting. Did you try GLFW.jl (or any other OpenGL-based package for that matter)? For me it segfaults when running its own test, when using the generic 64-bit Linux binary (since it works with Julia built from the source with the statically linked libllvm, I assume that this is the known bug of conflicting libllvm shared libraries).
If you’re willing to do at least the same amount of work as you would for a vanilla Arch install, Gentoo also works great. Compiles from git source cleanly everytime since about 2 years ago for me, and binary tarballs work fine as well. In some cases (other than LLVM), you can even build Julia to link against certain system-installed libraries, although I wouldn’t recommend that.
Of course, this all depends on how much time you’re willing to spend on setting up your distro. Gentoo’s base install is about 2-3 hours the first time if you closely follow the docs, but then you need to install, and thus automatically compile, all the packages you desire, since that’s how package installs work on a Gentoo system typically. Definitely not for everyone.
In general, as long as you aren’t using a distro with very old packages, or something exotic like NixOS, pretty much any Linux distro should work fine.
Arch. You always have the latest of any package you want with the least possible effort.
Sometimes you end up with something like a gfortran that is too new, and have to downgrade until things catch up. In comparison I’m often frustrated when using my ubuntu servers trying to get some packages I need that arent a year old.
Apparently Manjaro (built on top of arch) is easier to start with, so probably go with that.
Just for the record, I’ve had success with both binary distributions and local builds of Julia on Debian Stretch. (Leaving aside annoyances with libgfortran and libz which are documented elsewhere.) GLFW.jl and other OpenGL stuff work fine for me. You must have an unusual setup if GLFW needs LLVM. (Neither stock Debian libglfw.so, nor the one built by the Julia package for v0.6, links to LLVM libraries here). If you need complicated library chains because of peculiar video card support, that may well give you trouble on any distribution.
Indeed, ldd on julia’s libglfw.so (the only one installed on my debian box) does not show libllvm in the dependencies. However, here’s the stack trace I got when running the test on GLFW.jl:
(v1.0) pkg> test GLFW
Testing GLFW
Status `/tmp/tmpoY2qLY/Manifest.toml`
[9e28174c] BinDeps v0.8.10
[631607c0] CMake v1.0.2
[d5fb7624] CMakeWrapper v0.2.2
[34da2185] Compat v1.1.0
[f7f18e0c] GLFW v2.2.0
[d9be37ee] Homebrew v0.7.0
[682c06a0] JSON v0.19.0
[bac558e1] OrderedCollections v1.0.1
[d96e819e] Parameters v0.10.1
[30578b45] URIParser v0.4.0
[2a0f44e3] Base64 [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Base64`]
[ade2ca70] Dates [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Dates`]
[8bb1440f] DelimitedFiles [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/DelimitedFiles`]
[8ba89e20] Distributed [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Distributed`]
[b77e0a4c] InteractiveUtils [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/InteractiveUtils`]
[76f85450] LibGit2 [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/LibGit2`]
[8f399da3] Libdl [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Libdl`]
[37e2e46d] LinearAlgebra [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/LinearAlgebra`]
[56ddb016] Logging [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Logging`]
[d6f4376e] Markdown [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Markdown`]
[a63ad114] Mmap [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Mmap`]
[44cfe95a] Pkg [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Pkg`]
[de0858da] Printf [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Printf`]
[3fa0cd96] REPL [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/REPL`]
[9a3f8284] Random [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Random`]
[ea8e919c] SHA [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/SHA`]
[9e88b42a] Serialization [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Serialization`]
[1a1011a3] SharedArrays [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/SharedArrays`]
[6462fe0b] Sockets [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Sockets`]
[2f01184e] SparseArrays [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/SparseArrays`]
[10745b16] Statistics [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Statistics`]
[8dfed614] Test [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Test`]
[cf7118a7] UUIDs [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/UUIDs`]
[4ec0a83e] Unicode [`~/julia-1.0.0/bin/../share/julia/stdlib/v1.0/Unicode`]
signal (11): Segmentation fault
in expression starting at /home/kalugin/.julia/packages/GLFW/pkSlg/test/windowclose.jl:3
_ZN4llvm2cl16AddLiteralOptionERNS0_6OptionENS_9StringRefE at /home/kalugin/julia-1.0.0/bin/../lib/julia/libLLVM-6.0.so (unknown line)
unknown function (ip: 0x7f5522c8d30b)
unknown function (ip: 0x7f554f4c9be9)
unknown function (ip: 0x7f554f4c9cd2)
unknown function (ip: 0x7f554f4cde37)
unknown function (ip: 0x7f554f4c9aa3)
unknown function (ip: 0x7f554f4cd62a)
dlopen_doit at /build/glibc-6V9RKT/glibc-2.19/dlfcn/dlopen.c:66
unknown function (ip: 0x7f554f4c9aa3)
_dlerror_run at /build/glibc-6V9RKT/glibc-2.19/dlfcn/dlerror.c:163
__dlopen at /build/glibc-6V9RKT/glibc-2.19/dlfcn/dlopen.c:87
unknown function (ip: 0x7f55270bd0b5)
unknown function (ip: 0x7f55270c0b9b)
unknown function (ip: 0x7f5527095993)
glXQueryVersion at /usr/lib/x86_64-linux-gnu/libGL.so.1 (unknown line)
_glfwInitGLX at /home/kalugin/.julia/packages/GLFW/pkSlg/deps/usr/lib/libglfw.so (unknown line)
_glfwPlatformCreateWindow at /home/kalugin/.julia/packages/GLFW/pkSlg/deps/usr/lib/libglfw.so (unknown line)
glfwCreateWindow at /home/kalugin/.julia/packages/GLFW/pkSlg/deps/usr/lib/libglfw.so (unknown line)
CreateWindow at /home/kalugin/.julia/packages/GLFW/pkSlg/src/glfw3.jl:479
CreateWindow at /home/kalugin/.julia/packages/GLFW/pkSlg/src/glfw3.jl:479 [inlined]
CreateWindow at /home/kalugin/.julia/packages/GLFW/pkSlg/src/glfw3.jl:479
unknown function (ip: 0x7f55380734c1)
jl_fptr_trampoline at /buildworker/worker/package_linux64/build/src/gf.c:1829
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:324
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:428
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:363 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:686
jl_interpret_toplevel_thunk_callback at /buildworker/worker/package_linux64/build/src/interpreter.c:799
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x7f553f0e945f)
unknown function (ip: (nil))
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:808
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:787
jl_parse_eval_all at /buildworker/worker/package_linux64/build/src/ast.c:838
jl_load at /buildworker/worker/package_linux64/build/src/toplevel.c:821
include at ./boot.jl:317 [inlined]
include_relative at ./loading.jl:1038
include at ./sysimg.jl:29
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
include at ./client.jl:388
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:324
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:428
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:363 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:686
jl_interpret_toplevel_thunk_callback at /buildworker/worker/package_linux64/build/src/interpreter.c:799
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x7f553f0e855f)
unknown function (ip: 0x2)
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:808
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:787
jl_parse_eval_all at /buildworker/worker/package_linux64/build/src/ast.c:838
jl_load at /buildworker/worker/package_linux64/build/src/toplevel.c:821
include at ./boot.jl:317 [inlined]
include_relative at ./loading.jl:1038
include at ./sysimg.jl:29
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
include at ./client.jl:388
jl_fptr_trampoline at /buildworker/worker/package_linux64/build/src/gf.c:1829
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
do_call at /buildworker/worker/package_linux64/build/src/interpreter.c:324
eval_value at /buildworker/worker/package_linux64/build/src/interpreter.c:428
eval_stmt_value at /buildworker/worker/package_linux64/build/src/interpreter.c:363 [inlined]
eval_body at /buildworker/worker/package_linux64/build/src/interpreter.c:686
jl_interpret_toplevel_thunk_callback at /buildworker/worker/package_linux64/build/src/interpreter.c:799
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x7f553dbbbb1f)
unknown function (ip: 0xffffffffffffffff)
jl_interpret_toplevel_thunk at /buildworker/worker/package_linux64/build/src/interpreter.c:808
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:787
jl_toplevel_eval_flex at /buildworker/worker/package_linux64/build/src/toplevel.c:734
jl_toplevel_eval_in at /buildworker/worker/package_linux64/build/src/builtins.c:622
eval at ./boot.jl:319
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
macro expansion at ./logging.jl:317 [inlined]
exec_options at ./client.jl:219
_start at ./client.jl:421
jl_apply_generic at /buildworker/worker/package_linux64/build/src/gf.c:2182
jl_apply at /buildworker/worker/package_linux64/build/ui/../src/julia.h:1536 [inlined]
true_main at /buildworker/worker/package_linux64/build/ui/repl.c:112
main at /buildworker/worker/package_linux64/build/ui/repl.c:233
__libc_start_main at /build/glibc-6V9RKT/glibc-2.19/csu/libc-start.c:287
_start at /home/kalugin/julia-1.0.0/bin/julia (unknown line)
Allocations: 3387681 (Pool: 3386786; Big: 895); GC: 6
ERROR: Package GLFW errored during testing
It is also possible that the video card is to blame (for my box, this is an on-chip AMD/ATI controller Radeon HD 6530D), since there are other issues, such as WebGL not working in Chrome (but working in Firefox, go figure…)
Last time I tried Manjaro, the kernel was too old for my graphics card, so the graphical installer simply froze as soon as it loaded. I tried architect, but ran into some sort of dependency hell that – even though many others reported it and discussed solutions online – I could not resolve.
I gave up and installed Fedora. Fedora also froze, but only after logging in (after successfully installing). That let me ctrl + f2 => log in, sudo dnf update (updated to latest kernel), sudo reboot. Then everything has been pain free ever since.
Fedora might not be a rolling distro (and I’m not eager to switch to rawhide), but it’s on all the latest releases anyway, eg my computer is on gcc 8.1.1 and kernel 4.18.8 at the moment, so it satisfies that itch.
I installed Ubuntu with the same graphics card on another computer and didn’t run into any issues at all, even though Ubuntu has older kernels. I don’t know why/how.
Right now, Ubuntu 18.04 also has the advantage of being on gcc-7 (and libgfortran.so.4), which much of Julia currently assumes, but that might be an issue of the past.
You have my sympathy; video drivers have given me plenty of grief over the years.
This looks like a questionably built libGL.so - or some dependency thereof - which resolves external symbols promiscuously. It’s possible that a different distribution would have a more compatible implementation, but since some of the libGL stack is written by video card manufacturers with limited interest in the Linux desktop, it’s a gamble.
We didn’t see this from ldd libglfw.so because GLFW hunts for the GL stack at runtime, calling dlopen and dlsym directly instead of relying on information stored in the shared object. This means it could grab the wrong version of libGL.so, but from your report I don’t think that is your problem.
Incidentally, if you do decide to update your Linux distribution, be aware that AMD completely revised their Linux video drivers recently and may not properly support your chip with the new stuff. You can guess how I know about this.
After upgrading to debian stretch (9.5) the error is gone. It seems that it was a particularly unfortunate combination of the video card and the linux distribution that caused the problem.
EDIT: I somehow missed your last post. You made a choice and are happy. I won’t delete this post anyway. It might be useful.
The answer depends on what else you are doing with the machine, and whether you have a taste for linux hobbyism (see @jpsamaroo 's comment above). You can find posts on forums by people who have a personal machine and a work machine (or administer several) and use different distributions on them for different reasons.
Generally speaking, distributions with recent stuff (the stuff in Jessie appears to be mostly from Fall 2014) will have fewer problems building things. They will also be more unstable; e.g. will have more bugs in the packages and the system integration.
If you have not been otherwise bothered by being frozen in 2014 (which would be a good thing), you might consider an in-place upgrade to the next stable release.
I don’t use a distribution per se. For my private computers I have been using only debian, testing or unstable, for more than 20 years. I just looked now, it’s currently “testing”. But it’s not up to date. For a long time now I only upgrade a package when something stops working or there is some feature I want. So what I have is a hodgepodge. I have never downloaded a Julia binary. I have built Julia frequently since December 2015. In a sense, I have never had any problem building it out-of-the-box that was due to the OS. A few weeks ago, the master branch failed to build, something that has happened very rarely. The error message seemed to be related to a missing fortran header. So I tried upgrading gfortran, and that worked. I’m not counting that as a problem.
I have absolutely no taste for linux hobbyism. So, this situation is not ideal. But, I can go for long periods having what I want and no breakage. Sometimes I have to install another python in ~/.local, or hide a troublesome system binary that’s in a required package; things like that.
I’ll probably try a rolling distribution, like Arch, soon. In this thread people say it is easy to build Julia with one of these distributions and I’m not surprised because they are flexible and up to date. There are discussions elsewhere of the pros and cons of debian testing vs. a rolling distribution. My best guess is what is said in general applies to building Julia. Either way you’ll have to spend some time and some of your chore-tolerance reserve messing with your OS.
My recommendation is arch linux with i3 window manager and linux-rt-bfq kernel (optimized task scheduling for realtime), since that’s what I use. It isn’t everyone’s cup of tea, but after spending the proper time to set the system up, it is the best linux system I have used so far!
If you become familiar with arch you will likely become a better linux user and you will always have the very latest packages and software available. Sometimes, this causes issues when you have the latest software and you are trying to compile some outdated code (e.g. if it depends on gcc previous version for example), but you can usually find some way to make it work.
If you need something that works out of the box, arch won’t be the right choice. If you set up your arch system proper, it will be one of the best and most convenient systems you will ever have. The package manager is fantastic and the arch user repositories have pretty much anything else you might need to compile.
Building Julia on arch is easily possible, I’ve done it many times.