digitalmars.D.ldc - LDC 0.15.0 alpha1 released! Please help test!
- Kai Nacke (46/46) Oct 22 2014 Hi everyone!
- Trass3r (5/8) Oct 22 2014 Known issues:
- bearophile (4/19) Oct 22 2014 Is the 32 bit Windows version missing still?
- Kai Nacke (8/9) Oct 22 2014 I still have to create the mingw32 version. This will be part of
- Kiith-Sa (76/124) Oct 23 2014 I tried it with a project I'm working on, compilation works OK,
- Kai Nacke (16/99) Oct 24 2014 Thanks for trying LDC!
- David Nadlinger (14/21) Oct 24 2014 That's not the issue, it's something along the lines of -O3
- Kiith-Sa (3/26) Oct 25 2014 I've reduced the code needed to reproduce the issue:
- Daniel N (14/19) Oct 24 2014 Hi Kai,
- Kai Nacke (5/26) Oct 24 2014 Hi Daniel!
- Anonymus (50/50) Oct 24 2014 Not sure wether this is an issue at all: I get some strange
- David Nadlinger (4/7) Oct 24 2014 and neither different versions of any one D compiler.
- Marco Leise (12/16) Oct 31 2014 And that's why on Gentoo Linux I made it so GtkD is installed
- Andrei Amatuni (14/14) Oct 26 2014 Building DCD (d completion daemon) is failing for me. The build
- David Nadlinger via digitalmars-d-ldc (6/8) Oct 26 2014 This looks like it might just be a stupid mistake on _our_ part:
- Andrei Amatuni (7/16) Oct 26 2014 Hey David,
-
Steve
(9/15)
Nov 05 2014
- David Nadlinger via digitalmars-d-ldc (15/22) Nov 06 2014 Seems like your libc is older than the one the binary packages were
- Kai Nacke (9/26) Nov 08 2014 I am building the binaries on Ubuntu 12.04.5 LTS. The mentioned
Hi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3). This is a really exciting release! Support for the PowerPC architecture has grown. Linux/PPC64 Little Endian is quite usable. Linux/PPC32 compiles out of the box and can run simple application. There is still lot to do, though. Even more exciting this release comes with the first official development snapshot of a Win64 compiler targetting the MS C Runtime. Thanks to Trass3r and kinke for their active development! Please note that this version is really bleeding edge. Please help to find the bugs! This release does not include a mingw binary because of some build problems. This is on the todo list for alpha2 or beta1 release. Be sure to read the preliminary change log at the GitHub release page which also has the package download links: https://github.com/ldc-developers/ldc/releases/tag/v0.15.0-alpha1 MD5 checksums for the release packages: e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz 9d54267d1734373452563e57d46d831b ldc2-0.15.0-alpha1-linux-x86.tar.gz ace3a80431a57b7c88986da48a68d03c ldc2-0.15.0-alpha1-linux-x86.tar.xz cfce02ac3372f943b78adde982cb6059 ldc2-0.15.0-alpha1-linux-x86_64.tar.gz af0d70c77ef0fe3cb56255c8635a0c46 ldc2-0.15.0-alpha1-linux-x86_64.tar.xz 7d0d5f01de8b26b03017f4056db061d8 ldc2-0.15.0-alpha1-osx-x86_64.tar.gz 673a79025347e4d240e396ca71d0110d ldc2-0.15.0-alpha1-osx-x86_64.tar.xz 1be7e8ab0fa6b74ffb223aaf8d380a8d ldc2-0.15.0-alpha1-win64-msvc.zip Please be sure to report any bugs at https://github.com/ldc-developers/ldc/issues, and feel free to drop by at the digitalmars.D.ldc forums (http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or comments. Thanks to everybody involved in making this happen! Regards, Kai
Oct 22 2014
"Trass3r" <un known.com> Even more exciting this release comes with the first official development snapshot of a Win64 compiler targetting the MS C Runtime.Known issues: - broken varargs and thus array concatenation of more than 2 operands - poor debugging info. Make some noise on cfe-dev to get that fixed as it also affects clang-cl ;)
Oct 22 2014
Kai Nacke:e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz 9d54267d1734373452563e57d46d831b ldc2-0.15.0-alpha1-linux-x86.tar.gz ace3a80431a57b7c88986da48a68d03c ldc2-0.15.0-alpha1-linux-x86.tar.xz cfce02ac3372f943b78adde982cb6059 ldc2-0.15.0-alpha1-linux-x86_64.tar.gz af0d70c77ef0fe3cb56255c8635a0c46 ldc2-0.15.0-alpha1-linux-x86_64.tar.xz 7d0d5f01de8b26b03017f4056db061d8 ldc2-0.15.0-alpha1-osx-x86_64.tar.gz 673a79025347e4d240e396ca71d0110d ldc2-0.15.0-alpha1-osx-x86_64.tar.xz 1be7e8ab0fa6b74ffb223aaf8d380a8d ldc2-0.15.0-alpha1-win64-msvc.zipIs the 32 bit Windows version missing still? Bye, bearophile
Oct 22 2014
Hi bearophile! On Wednesday, 22 October 2014 at 19:49:28 UTC, bearophile wrote:Is the 32 bit Windows version missing still?I still have to create the mingw32 version. This will be part of the next alpha/beta release. A version targetting Win32 with MS C Runtime is still missing because there is no exception support for 32bit SEH in LLVM. Regards, Kai
Oct 22 2014
On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:Hi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3). This is a really exciting release! Support for the PowerPC architecture has grown. Linux/PPC64 Little Endian is quite usable. Linux/PPC32 compiles out of the box and can run simple application. There is still lot to do, though. Even more exciting this release comes with the first official development snapshot of a Win64 compiler targetting the MS C Runtime. Thanks to Trass3r and kinke for their active development! Please note that this version is really bleeding edge. Please help to find the bugs! This release does not include a mingw binary because of some build problems. This is on the todo list for alpha2 or beta1 release. Be sure to read the preliminary change log at the GitHub release page which also has the package download links: https://github.com/ldc-developers/ldc/releases/tag/v0.15.0-alpha1 MD5 checksums for the release packages: e9932001d1a220300cdb06e624a42e51 ldc-0.15.0-alpha1-src.tar.gz 9d54267d1734373452563e57d46d831b ldc2-0.15.0-alpha1-linux-x86.tar.gz ace3a80431a57b7c88986da48a68d03c ldc2-0.15.0-alpha1-linux-x86.tar.xz cfce02ac3372f943b78adde982cb6059 ldc2-0.15.0-alpha1-linux-x86_64.tar.gz af0d70c77ef0fe3cb56255c8635a0c46 ldc2-0.15.0-alpha1-linux-x86_64.tar.xz 7d0d5f01de8b26b03017f4056db061d8 ldc2-0.15.0-alpha1-osx-x86_64.tar.gz 673a79025347e4d240e396ca71d0110d ldc2-0.15.0-alpha1-osx-x86_64.tar.xz 1be7e8ab0fa6b74ffb223aaf8d380a8d ldc2-0.15.0-alpha1-win64-msvc.zip Please be sure to report any bugs at https://github.com/ldc-developers/ldc/issues, and feel free to drop by at the digitalmars.D.ldc forums (http://forum.dlang.org/group/digitalmars.D.ldc) for any questions or comments. Thanks to everybody involved in making this happen! Regards, KaiI tried it with a project I'm working on, compilation works OK, but I'm getting extremely bad performance (50-100x overhead compared to DMD) - profiling has shown that some code that should execute at compile-time seems to run at run-time. I never used LDC before, I don't know if this is a bug or I'm doing something wrong - I'm using LDC through DUB, so I didn't specify command-line args directly. (tried both debug and release builds, but args were passed by DUB) Can't publish the project (yet), but here's a part of a function annotated by the profiler (perf): bool matchComponents(ComponentTypeIDs...)() push %rbp mov %rsp,%rbp { // Type IDs of processed component types. enum processedIDs = componentIDs!ProcessedComponents; sub $0x70,%rsp mov $0x68dae0,%eax mov %eax,%ecx mov $0x4,%eax mov %eax,%esi mov %rdi,-0x40(%rbp) mov %rcx,%rdi → callq _d_newarrayU movw $0x28,0x6(%rdx) movw $0x25,0x4(%rdx) movw $0x21,0x2(%rdx) movw $0x1,(%rdx) enum sortedIDs = std.algorithm.sort([ComponentTypeIDs]); mov $0x68e210,%r8d mov %r8d,%edi mov $0x3,%r8d mov %r8d,%esi mov %rax,-0x48(%rbp) → callq _d_newarrayU .. etc Note the _d_newarrayU - it seems the array literal is allocated despite only being used at compile-time? On the other hand, sort() doesn't seem to be called. Same function with DMD (the 'enum' lines don't even show up): /// Determine if the current entity contains specified component types. bool matchComponents(ComponentTypeIDs...)() push %rbp mov %rsp,%rbp sub $0x18,%rsp push %rbx mov %rdi,-0x8(%rbp) mov -0x8(%rbp),%rax mov (%rax),%rcx lea 0x358(%rax),%rdx cmp (%rdx),%rcx ↓ jb 2a mov $0x1f1,%edi → callq _D7tharsis6entity11entityrange7__arrayZ 2a: mov (%rax),%rbx mov (%rdx),%rax mov 0x8(%rdx),%rdx mov (%rdx,%rbx,2),%cx neg %cx sbb %ecx,%ecx neg %ecx mov %cl,-0x10(%rbp) return parts.join(" && "); } // The actual run-time code is here. mixin(q{const result = cast(bool)(%s);}.format(matchCode())); return result; mov -0x10(%rbp),%al } pop %rbx leaveq ← retq
Oct 23 2014
Hi Kiith-Sa! On Friday, 24 October 2014 at 00:50:51 UTC, Kiith-Sa wrote:On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:Thanks for trying LDC! CTFE is done in the frontend therefore there should be no difference between LDC and DMD. But a bug can always creep in...Hi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).I tried it with a project I'm working on, compilation works OK, but I'm getting extremely bad performance (50-100x overhead compared to DMD) - profiling has shown that some code that should execute at compile-time seems to run at run-time. I never used LDC before, I don't know if this is a bug or I'm doing something wrong - I'm using LDC through DUB, so I didn't specify command-line args directly. (tried both debug and release builds, but args were passed by DUB)Can't publish the project (yet), but here's a part of a function annotated by the profiler (perf):We really prefer reduced test cases. :-) If you can produce one that would be really great.bool matchComponents(ComponentTypeIDs...)() push %rbp mov %rsp,%rbp { // Type IDs of processed component types. enum processedIDs = componentIDs!ProcessedComponents; sub $0x70,%rsp mov $0x68dae0,%eax mov %eax,%ecx mov $0x4,%eax mov %eax,%esi mov %rdi,-0x40(%rbp) mov %rcx,%rdi → callq _d_newarrayU movw $0x28,0x6(%rdx) movw $0x25,0x4(%rdx) movw $0x21,0x2(%rdx) movw $0x1,(%rdx) enum sortedIDs = std.algorithm.sort([ComponentTypeIDs]); mov $0x68e210,%r8d mov %r8d,%edi mov $0x3,%r8d mov %r8d,%esi mov %rax,-0x48(%rbp) → callq _d_newarrayU .. etc Note the _d_newarrayU - it seems the array literal is allocated despite only being used at compile-time? On the other hand, sort() doesn't seem to be called. Same function with DMD (the 'enum' lines don't even show up): /// Determine if the current entity contains specified component types. bool matchComponents(ComponentTypeIDs...)() push %rbp mov %rsp,%rbp sub $0x18,%rsp push %rbx mov %rdi,-0x8(%rbp) mov -0x8(%rbp),%rax mov (%rax),%rcx lea 0x358(%rax),%rdx cmp (%rdx),%rcx ↓ jb 2a mov $0x1f1,%edi → callq _D7tharsis6entity11entityrange7__arrayZ 2a: mov (%rax),%rbx mov (%rdx),%rax mov 0x8(%rdx),%rdx mov (%rdx,%rbx,2),%cx neg %cx sbb %ecx,%ecx neg %ecx mov %cl,-0x10(%rbp) return parts.join(" && "); } // The actual run-time code is here. mixin(q{const result = cast(bool)(%s);}.format(matchCode())); return result; mov -0x10(%rbp),%al } pop %rbx leaveq ← retqI do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch. Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz forum.dlang.org). Using -singleobj with multiple objects might help, too. Regards, Kai
Oct 24 2014
On Friday, 24 October 2014 at 16:28:13 UTC, Kai Nacke wrote:I do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch.That's not the issue, it's something along the lines of -O3 -release -disable-boundscheck by default.Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz forum.dlang.org). Using -singleobj with multiple objects might help, too.The issues is most probably not related to optimization at all. I obviously can't say any definitive without more context/code, but it looks like we might emit a manifest constant once and unconditionally instead of on every use (there is/was even an ancient fixme note about this in the code at some point). CTFE itself seems not to be directly related to the issue. It only happens to produce the initializer we erroneously emit afterwards. And regarding the optimizer, the only thing we could there is to catch that the value is never used/escaped and elide it, but clearly it just shouldn't be there in the first place. David
Oct 24 2014
On Friday, 24 October 2014 at 21:21:40 UTC, David Nadlinger wrote:On Friday, 24 October 2014 at 16:28:13 UTC, Kai Nacke wrote:I've reduced the code needed to reproduce the issue: https://github.com/ldc-developers/ldc/issues/762I do not use DUB so I don't know which args were passed to LDC. I would assume that release only passes the -release switch.That's not the issue, it's something along the lines of -O3 -release -disable-boundscheck by default.Could you try it again with a higher optimization level, e.g. -O2 or -O3? There is also a problem with the inliner (David gave some hints here: http://forum.dlang.org/post/ursgarblzengucvxnmfz forum.dlang.org). Using -singleobj with multiple objects might help, too.The issues is most probably not related to optimization at all. I obviously can't say any definitive without more context/code, but it looks like we might emit a manifest constant once and unconditionally instead of on every use (there is/was even an ancient fixme note about this in the code at some point). CTFE itself seems not to be directly related to the issue. It only happens to produce the initializer we erroneously emit afterwards. And regarding the optimizer, the only thing we could there is to catch that the value is never used/escaped and elide it, but clearly it just shouldn't be there in the first place. David
Oct 25 2014
On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:Hi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).Hi Kai, wow looks like an amazing release, I did spot a minor issue, the descriptive text for ldmd2 is outdated when it comes to boundscheck. DMD32 D Compiler v2.066.1 -boundscheck=[on|safeonly|off] bounds checks on, in safe only, or off -noboundscheck no array bounds checking (deprecated, use -boundscheck=off) LDC - the LLVM D compiler (aa0cc4): based on DMD v2.066.1 and LLVM 3.6.0git Default target: x86_64-pc-windows-msvc -noboundscheck turns off array bounds checking for all functions
Oct 24 2014
On Friday, 24 October 2014 at 11:35:10 UTC, Daniel N wrote:On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:Hi Daniel! Thanks for the report. This is really unimplemented functionality. Regards, KaiHi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3).Hi Kai, wow looks like an amazing release, I did spot a minor issue, the descriptive text for ldmd2 is outdated when it comes to boundscheck. DMD32 D Compiler v2.066.1 -boundscheck=[on|safeonly|off] bounds checks on, in safe only, or off -noboundscheck no array bounds checking (deprecated, use -boundscheck=off) LDC - the LLVM D compiler (aa0cc4): based on DMD v2.066.1 and LLVM 3.6.0git Default target: x86_64-pc-windows-msvc -noboundscheck turns off array bounds checking for all functions
Oct 24 2014
Not sure wether this is an issue at all: I get some strange
behaviour when I try to mix dmd and LDC generated *.o-files:
//versions:
DMD64 D Compiler v2.066.0
linux-x86_64 LDC
//code:
module a;
int foo(int a) {
return a;
}
module b;
import a;
import std.stdio;
void main() {
writeln(foo(2));
}
dmd a.d -c
ldc2 b.d a.o
./b
output:
object.Exception /build/src/ldc/runtime/phobos/std/stdio.d(2156):
Enforcement failed
dmd a.d -c
ldc2 b.d -c
ldc2 b.o a.o
./b
output:
2
dmd b.d -c
ldc2 b.o a.d
output:
b.o: In Funktion
`_D3std9exception105__T12errnoEnforceTiVAyaa35_2f7573722f696e636c7564652f646d642f70686f626f732f7374642f737464696f2e64Vmi2113Z12errnoEnforceFNfiLAyaZi':
b.d:(.text._D3std9exception105__T12errnoEnforceTiVAyaa35_2f7573722f696e636c7564652f646d642f70686f626f732f7374642f737464696f2e64Vmi2113Z12errnoEnfo
ceFNfiLAyaZi+0x6a):
Nicht definierter Verweis auf `_d_throwc'
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
If dmd does the linking, there are even more different results...
I also have a ldc version build from github source at 20.10.2014
(0.14 was broken for me) where I get
dmd -c a.d
ldc2 b.d a.o
./b
2
Ungültiger Maschinenbefehl
Note that I usually compile everything with the same compiler and
LDC 0.15 seems to work fine. The only minor problem is that I
can't use the compilation speed of dmd during development because
it is unable to link against my gtkd (compiled by an old LDC
version) - not sure wether that is related.
Oct 24 2014
On Friday, 24 October 2014 at 20:56:28 UTC, Anonymus wrote:Not sure wether this is an issue at all: I get some strange behaviour when I try to mix dmd and LDC generated *.o-files.DMD and LDC are indeed not ABI compatible right now,(compiled by an old LDC version)and neither different versions of any one D compiler. David
Oct 24 2014
Am Fri, 24 Oct 2014 20:56:27 +0000 schrieb "Anonymus" <a b.com>:The only minor problem is that I can't use the compilation speed of dmd during development because it is unable to link against my gtkd (compiled by an old LDC version) - not sure wether that is related.And that's why on Gentoo Linux I made it so GtkD is installed once per dmd version, ldc2 version, gdc version and pointer size. So on Gentoo you can unleash the speed of DMD with installed D libraries and also compile your release versions with ldc2 or gdc. Just remember not to mix object files produced by different compilers or different compiler versions. Some APIs in Phobos changed even from 2.066.0 to 2.066.1. -- Marco
Oct 31 2014
Building DCD (d completion daemon) is failing for me. The build
works with DMD though. It was failing with the same error on
0.14.0 too, so it's not something new. I'm on OS X. It might just
be a stupid mistake on my part. Here's my error message:
Undefined symbols for architecture x86_64:
"__D4core8internal4hash9bytesHashFNaNbNePxvmmZm", referenced
from:
__D11modulecache10CacheEntry6toHashMxFNbNfZm in
modulecache.o
__D4core8internal4hash16__T6hashOfTxAyaZ6hashOfFNaNbNeKxAyamZm in
modulecache.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
Oct 26 2014
Hi Andrei, On 27 Oct 2014, at 2:24, Andrei Amatuni via digitalmars-d-ldc wrote:It might just be a stupid mistake on my part. […] "__D4core8internal4hash9bytesHashFNaNbNePxvmmZm" […]This looks like it might just be a stupid mistake on _our_ part: https://github.com/ldc-developers/ldc/pull/770 Cheers, David
Oct 26 2014
On Monday, 27 October 2014 at 02:32:35 UTC, David Nadlinger via digitalmars-d-ldc wrote:Hi Andrei, On 27 Oct 2014, at 2:24, Andrei Amatuni via digitalmars-d-ldc wrote:Hey David, Thanks for the quick response! I was almost sure it was my fault. Spent some time tinkering with ldflags/library_path but still no luck. Hopefully this takes care of it. AndreiIt might just be a stupid mistake on my part. […] "__D4core8internal4hash9bytesHashFNaNbNePxvmmZm" […]This looks like it might just be a stupid mistake on _our_ part: https://github.com/ldc-developers/ldc/pull/770 Cheers, David
Oct 26 2014
On Wednesday, 22 October 2014 at 18:28:44 UTC, Kai Nacke wrote:Hi everyone! On behalf of the LDC team I am proud to announce the LDC 0.15.0 alpha1 release! It is based on the 2.066.1-rc2 front-end and LLVM 3.1-3.5 (OS X: no support for 3.3). This is a really exciting release!<snip> I have an up-to-date version of Crunchbang running on a Thinkpad R52. Starting with version 0.13, I get ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2) ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2) when trying to run the binary images. This keeps me at 0.12.
Nov 05 2014
On 5 Nov 2014, at 17:32, Steve via digitalmars-d-ldc wrote:I have an up-to-date version of Crunchbang running on a Thinkpad R52. Starting with version 0.13, I get ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2) ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2) when trying to run the binary images. This keeps me at 0.12.Seems like your libc is older than the one the binary packages were built against. Kai has been building the release packages since I handed over maintainership to him, but generally our strategy is to build them on the second-to-last Ubuntu LTS release. Right now, this is 12.04, which over 2.5 years old at this point. Generally, we've found this to be enough for the vast majority of users to be able to just use the binary releases. If you want to use it on an older system, you can always compile it from source yourself. By the way, thanks to Konstantinos are now Debian packages for LDC. I've no idea how feasible it is to backport them to whatever Crunchbang is using, but it might simplify things. Regards, David
Nov 06 2014
On Thursday, 6 November 2014 at 20:29:53 UTC, David Nadlinger via digitalmars-d-ldc wrote:On 5 Nov 2014, at 17:32, Steve via digitalmars-d-ldc wrote:I am building the binaries on Ubuntu 12.04.5 LTS. The mentioned libstdc++ version is indeed used. Starting with release 0.1.50, the only difference to a vanilla 12.04 LTS is the backported gcc 4.8.1 which is required to compile LLVM 3.5+ Regards, KaiI have an up-to-date version of Crunchbang running on a Thinkpad R52. Starting with version 0.13, I get ldc2: /usr/lib/i386-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.18' not found (required by ldc2) ldc2: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ldc2)Kai has been building the release packages since I handed over maintainership to him, but generally our strategy is to build them on the second-to-last Ubuntu LTS release. Right now, this is 12.04, which over 2.5 years old at this point. Generally, we've found this to be enough for the vast majority of users to be able to just use the binary releases. If you want to use it on an older system, you can always compile it from source yourself.
Nov 08 2014