Change:
license = stdenv.lib.licenses.mit; maintainers = with stdenv.lib.maintainers; [ raskin ]; platforms = [ "i686-linux" "x86_64-linux" "x86_64-darwin" ]; <del> broken = stdenv.isi686; </del> <ins> broken = true; # since 2017-04-08. </ins> }; }

Discussion:
The issue is described here: Short: an error in a running a script causes a segfault instead of reporting the error. The hypothesis is a compiler mismatch just run a script containing any kind of error in julia 0.6
Hmm, having troubles reproducing, in the future please provide a bit more information (see the issue template for easy way to generate this with ). How did you get julia 0.6.0? On latest 17.09 channel: default for julia is 0.4.7 () Julia 0.5 is available as is marked as broken-- no 0.6 here. On latest unstable: default for julia is (not ) it appears is ? Building presently, we'll see if I see the same problem (I expect so). In the meantime, how about switching to a stable julia release, presumably with improvements and fixes? Using julia 0.6.2 (available from the binary cache, hooray!) I don't see the error you're experiencing. Depending on how you installed , and your system setup, something like one of the following should do the trick: or or, I guess: Hope this helps, good luck!
Nope, julia-git fails to build -- looks like last successful build was 2017-04-08 (!), probably should go back to being marked broken. (you probably have it julia 0.6.0 from the period where that was the supported nixpkgs version, not from julia-git, I'd guess)
Well, 0.6.2 has the same problem…
Err, it does! (?!) I really thought I confirmed it didn't, not sure what that's about. Sorry O:).
Maybe I use a version from a slightly obsolete master and it got fixed? In other news, compiler version conflict seems unlikely…
Hm, current master. Basically, once you have REPL, everything is fine, if you get an error before/without REPL, there are problems. and have the same problem. Edit: loading a file inside REPL works fine, yes.
Hi, sorry for the bad report. I was on julia 0.6.0 indeed, on nixos-unstable.

Upgraded the system today: nix-info julia -v And the segfault on scripts still exists. OT: why do we still have julia 0.4.7 in the repo? Also 0.5.0. They are outdated, and nothing depends on them in the store. As you said, julia-git is older than julia... it seems that we need a cleanup, also given that the new Pkg3 is coming and we might want to add julia pkgs too in the future
I have also noticed this problem. Additional info: it persists even in FHS-compatible environments, if that matters. Also, this is interesting: errors work fine if typed in at the REPL. If I then define a file named containing the single line , I get a segfault running (output at bottom, let me know if I should move it to a gist). However, including the file from the REPL does not cause problems. Finally, I tried defining a function that just immediately calls . If the function was called from the REPL, things were fine; if it was called in code invoked from the shell, it segfaulted. Segfault output: nix-info:
Yes the difference between the REPL and scripts is the behaviour I noticed. In the fhs you are running upstream julia?
Previously, no, I was just using julia from nixpkgs. However, if I build an FHS-compatible env with only , and download the generic Julia binary from their site, the problem actually does disappear. to make the nix shell:
Also, I would add that I have observed these segfaults from the REPL, but only while trying to install packages where the builds failed.
Yeah if I remember well package install spawns a new julia process
So upstream binary carries its own copy of LLVM and other things? I wonder if replacing them with symlinks to Nixpkgs-built ones in a FHS is a viable problem-localisation idea.
There's lots of files for LLVM (v 3.9), gcc/gfortran etc, under . I'm a new enough nix user that I'm not sure how to find the actual compiled libraries, but that sounds viable. It should be enough to just download from the website.
Fixed by