Nightlies for 0.3.0

[ViralBShah]

IIRC, we used to have nightlies for the mac at one point, and I believe that the ubuntu nightlies keep coming.

It would be nice to have the nightlies back on the downloads page.

[staticfloat]

I will do this once I get the windows nightlies working properly. Right now, I'm waiting on #5142 for windows builds, and #5095 for Ubuntu. (That last one will reduce the workload of fixing nightlies when they break significantly, so it'd be great to have it merged as soon as it's ready)

[WestleyArgentum]

Out of curiosity, what's the status here?

It seems like the current Ubuntu nightlies don't include the static compilation work (based on the amount of time they take to start up), which confuses me. I'm not sure if I'm just doing something wrong, if I should file an issue, or if my problem is part of this...

[JeffBezanson]

sys.so is not included in binary distributions yet, I believe.

[staticfloat]

Yes. The show startup time is because we can't ship the .so file yet for
some reason
On Jan 13, 2014 3:32 PM, "Jeff Bezanson" notifications@github.com wrote:

sys.so is not included in binary distributions yet, I believe.

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

[staticfloat]

Jameson, what exactly is incompatible when we distribute the .so files?
Each .deb created is OS and architecture specific.
On Jan 13, 2014 4:06 PM, "Elliot Saba" staticfloat@gmail.com wrote:

Yes. The show startup time is because we can't ship the .so file yet for
some reason
On Jan 13, 2014 3:32 PM, "Jeff Bezanson" notifications@github.com wrote:

sys.so is not included in binary distributions yet, I believe.

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

[WestleyArgentum]

@vtjnash

[vtjnash]

The .so file is specific to the processor feature set

[staticfloat]

So do we need to have some kind of first-time setup that gets run where we statically compile sys.so on user's machines? In order to do that will we need to ship llc or can it all be done from Julia directly?

[nalimilan]

I was thinking that it could be useful to be able to build several sys.so, each for a separate processor family, and let Julia pick the best one on startup (like OpenBLAS does). This is because in distribution packages we are forced to support relatively broad CPU families (i.e. i386, i686, x86_64): if Julia gets an important speed gain by using the newest instructions like SSE4 and AVX, then distribution packages will not be optimal since we cannot rely on them. Just a suggestion.

[tknopp]

isn't it possible to store multiple code path for different architectures into the same shared library? I use this under Windows with Visual Studio.

[nalimilan]

FatELF supports gluing several binaries into a single ELF file, but only on Linux currently: https://icculus.org/fatelf/ But I don't think it's geared towards supporting fine-grained features like SSE4 or AVX, rather large CPU families. Also, since you don't gain anything by putting everything in a single file here, that's probably not worth the pain. Instead, Julia could just build a filename from the CPU model and try to load the corresponding library.

[Keno]

@staticfloat The links on status.julialang.org don't actually point to anything. Is that intended?

[staticfloat]

Alright. The links have been updated to what they will eventually point to. The windows binaries are currently broken (I'm getting a compilation error) but the other binaries should be up and running right now. Once I get the windows binaries compiling correctly again the links should work.

[staticfloat]

Can someone please test http://s3.amazonaws.com/julialang/bin/winnt/x86/0.3/julia-0.3.0-prerelease.exe for me? I'm running into a test failure on Windows, but I'm not sure what is and isn't expected to fail.