Old apt-get packages

[CecilWard]

I noticed that the version of the apt-get xz-utils package (which I presume contains the xz compressor/decompressor exe) is really really old. What's worrying is that it's an _alpha_ version and there is source-code and some built versions of a 'stable' release on the project website.

Same with the apt-get package for GDC, compiler for the D programming language (http://dlang.org) compiler from the GCC collection, which is also ancient.

Is this kind of issue something I could fix myself in general? (Having zero knowledge of Linux though, although a very experienced professional C systems dev, just never on *nix.)

Also I don't want to have to fight the apt-get system either though, getting into a situation where some future apt-get operation will simply overwrite good new files - if I manage to get them pre-built [no luck] or even build them - with the ancient ones again, or ever just delete them.

[klricks]

Raspbian is based on Debian which has a very conservative and strict upgrade policy.
So most packages are several versions if not years older than what might be available elsewhere. In general you only get security updates between major releases (2 years).

If you upgrade to Stretch then you will get much newer packages. For example LibreOffice is 4.3.3.2 in Jessie and 5.2.7.2 in Stretch

If you want newer then you will have to obtain source code and compile yourself.

[fruitoftheloom]

I noticed that the version of the apt-get xz-utils package (which I presume contains the xz compressor/decompressor exe) is really really old. What's worrying is that it's an _alpha_ version and there is source-code and some built versions of a 'stable' release on the project website.

Same with the apt-get package for GDC, compiler for the D programming language (http://dlang.org) compiler from the GCC collection, which is also ancient.

Is this kind of issue something I could fix myself in general? (Having zero knowledge of Linux though, although a very experienced professional C systems dev, just never on *nix.)

Also I don't want to have to fight the apt-get system either though, getting into a situation where some future apt-get operation will simply overwrite good new files - if I manage to get them pre-built [no luck] or even build them - with the ancient ones again, or ever just delete them.

If you want latest and greatest then Arch Linux Arm is a Rolling Release and has newer packages ie xz is at present 5.2.3 compared to 5.2.2 in Stretch and 5.1.1 in Jessie:

https://archlinuxarm.org/

[CecilWard]

A couple of questions following on from that very useful reply:

Is it possible to do an upgrade install to arch Linux from within Linux - sounds impossible? Mind you, since I really need to move everything to a decent reliable fast larger micro (is it?) SD card for the pi3, not continuing the mistake of using the random card that came with it, perhaps I would be better starting off with a clean arch Linux install on that new card and forget about that idea. But then I would be back to square one, requiring physical help from someone to do the install (see my earlier post on headless + disability).

I though I saw a mention of an aarch64 version of arch Linux. Is there any chance at all of that running on a pi 3, or are various bits of software lacking? I would be very interested in that as I would like to look into some 64-bit ARM asm development as a learning project.

[CecilWard]

I should have spilt off that last post as a different topic, for greater visibility.

And is upgrading to stretch something that requires a bare-metal installation?

[CecilWard]

I could get source code and compile / make it myself if I had any idea which directories the results were supposed to be placed in, plus details,of other things like environment variables required. That's not a problem as I am a professional asm + C programmer, yet, amazingly, have never used unix before, ever. Not even at university, a million years ago (TOPS10 on a DEC 10 back then, plus microprocessors, just briefly saw unix on a PDP11 and a VAX11/780.)

I got hold of the new D compiler and related tools' exes, the runtime library and the D equivalent of header files (D itself doesn't use header files, just module references and compiler magic) and other stuff - all in a compressed tar file - but had no idea at all where to park it all, so was stuck. There may be some installation howto somewhere but I had no idea where to look. Would be better off if there were a batch file to simply automate an install of binaries or even a combined batch file to do a total [toolset install+make+copying of result stuff to system destinations]. I would write a .sh file for the benefit of others, if I knew what I was supposed to be doing.

[CecilWard]

Actually recompiling stuff from source would be an excellent idea as in some cases I could use newer (e.g. C, C++ etc )compilers, with better optimisation abilities and possibly find more aggressive (or more effective) optimisation switches in order to get higher performance resulting exes.

[jahboater]

I could get source code and compile / make it myself if I had any idea which directories the results were supposed to be placed in, plus details,of other things like environment variables required.

On Linux source package installation should finish with "sudo make install" which will put it all in the right places. Commonly the sequence is ./configure && make && sudo make install
You can control where things go with the --prefix= argument to the ./configure line, but the default will work fine. A large project such as the GCC compiler is a little more complicated (and will take a few hours to compile) but will still finish with make install (I can help with GCC, I do it routinely on all Pi's).

There is no 64-bit version of Raspbian (sadly since it is a very good distro for the Pi), but there are several alternatives. You can easily develop A64 assembler on any 64-bit Linux for the Pi. The Pi3 and the later Pi2's are ARMv8 (Cortex-a53) so can run either in 32-bit mode or in 64-bit mode (Aarch64).

Linux and the Pi, like UNIX, is a superb software development platform.

[CecilWard]

I saw that a raspberry pi hosting outfit based in Arizona not only host pis but they also have some other (alpha setup) hardware on offer that has aarch64 processors and a proper 64-bit o/s for it that works. It's some evaluation development board that they will host, which contains some 8-core ARM 64 device.

That would be very interesting to me as I would like to write some ARM64 asm. I've been writing some x86-64 asm code to contribute to the D language’s runtime library in order to provide users with zero-overhead access to various important new x64 instructions (like the Intel and Microsoft x86 ‘intrinsics’ for their C/C++). The D language also has built-in support for inline asm by some mechanism or other. (Unfortunately the three current D compilers ('DMD' from Digital Mars, ' GDC' and 'LDC') all implement asm support in completely different syntactically-incompatible ways, in that even the D framework code around the asm is not the same, never mind the kind of assembly language syntax used within the asm block itself.) My hope is that users can get fully inlined resulting code, like a macro with everything exposed literally in a header file, with generics’ template specialisation optimisations and proper idiomatic operand expression of an instruction’s arguments rather than it merely being just like an ordinary external subroutine call with the overhead of having to generate unnecessary code to pass parameters according to a rigid calling convention.

I'd also like to get an aarch64-target build of the GDC (D language in the GCC family) and LDC D (D with LLVM tech) compilers going if at all possible - unless someone has done it already, of course. Those compilers etc presumably will rely on the GCC and LLVM toolchchains respectively for building from C or C++. I don't recall how much of the D compiler front end is written in D (yet). The D compilers were certainly all in either C or C++, at least to begin with, obviously. The reference DMD compiler contributes source code for its front and middle end to the GDC and LDC projects The D runtime library is afaik all written entirely in D, apart from possibly a very rare bit of asm.

Anyway, I digress, in a major fashion. I'd like to tackle some ARM assembler for the first time anyway, not just x64 all the time. Add that to the list of various different CPUs for which I've written mountains of assembly language at work many years back.

[jahboater]

I saw that a raspberry pi hosting outfit based in Arizona not only host pis but they also have some other (alpha setup) hardware on offer that has aarch64 processors and a proper 64-bit o/s for it that works. It's some evaluation development board that they will host, which contains some 8-core ARM 64 device.

Also take a look at the Odroid C2 - the official OS for that is 64-bit (its the same Cortex-A53 ARMv8 CPU).

Anyway, I digress, in a major fashion. I'd like to tackle some ARM assembler for the first time anyway, not just x64 all the time.

ARM assembler usually refers to 32-bit ARM (A32 and T32) which you can develop on the Pi with the official Raspbian OS. Though I personally much prefer A64 (Aarch64 mode) as it is more modern and streamlined.