texlua issue on raspberry pi

[Johannes Hielscher]

Am Fri, 15 Apr 2022 17:24:07 -0400
schrieb Tom Kacvinsky <tkacvins at gmail.com>:

> On Fri, Apr 15, 2022 at 5:01 PM Henri Menke via tex-live
> <tex-live at tug.org> wrote:
> 
> > On Fri, 2022-04-15 at 22:56 +0200, Reinhard Kotucha wrote:  
> > > On 2022-04-15 at 15:52:07 -0400, Bob Tennent wrote:
> > >  
> > >  >> Please make sure that you are running Raspian 11 (Bullseye)
> > >  >> since that's what the armhf binaries of TeX Live have been
> > >  >> compiled  
> > > for.  
> > >  >
> > >  > Apparently I'm not but I have no intention of updating the
> > >  > operating system on this device. Is there no alternative
> > >  > approach? I suppose I could reinstall TL2021, which didn't
> > >  > have this issue.  
> > >
> > > It's definitely not desirable to compile the binaries with the
> > > latest OS release, just in order to avoid these nasty libc
> > > problems.  
> >
> > Yes and no. It's not desirable if you are on an older version of
> > Raspbian, but newer versions of the Raspberry Pi hardware cannot be
> > targeted by the old GCC, so either you end up with binaries that do
> > not run on old Raspbian or ones that do not run on newer boards.
> > Pick your poison.
> >
> >  
> I'm a little perplexed here -  are you saying an older GCC does not
> have a -march
> option for the newer hardware?   Maybe the default architecture is
> right, but there
> is an issue with the defaults for -mtune.  Could be tweaking -mtune
> to be more
> generic would do the trick.  I am thinking of neon - not sure if the
> isns change for
> the newer hardware, but you'd think the new hardware would support
> the neon isns
> in a binary produced by an older GCC (because the neon instruction
> set is "fixed"
> in some sense of fixed).

Oh plz, don't start me with Neon :-P
Point is, some RPi hardware speaks Neon, some not. Not all of the CPUs
understand the full ARMv7 instruction set. Rather the least common
denominator is “ARMv6.5”, a weird hybrid that pulled some stuff (but
not all) from ARMv7.
That makes it so difficult for compilers to target RPi hardware.

Broadcom had not designed these SoCs with a vivid FOSS/open hardware/
hacker community in mind. And to make things worse, the RPi Foundation
needed 7 (in words: seven) years to overcome their unconditional
downwards compatibility dogma, and finally released a flavour that
would allow their AArch64-capable CPUs (first released in 2015) to
natively run AArch64 code and make calls to AArch64 libraries.

Supposedly there are multiarch efforts in the RPi world (think of the
i686→x86_64 transition), but I myself couldn't be bothered to give them
a try. Neither with cross-compile toolchains etc.
Things would have been easier if the RPi ecosystem had been more eager
to adhere to commonly accepted standards, instead of trying to push
their own.
Sorry, Bob, that this doesn't help you out.

Best,
Johannes

> 
> I also suppose it could be the difference between the original RiPIs
> being 32-bit and
> the newer generation being aarch64.
> 
> One other thought I had -  it might be an issue with the binutils
> used by the older distros.
> There has been quite a bit of work on aarch64 support in binutils
> over the last year or
> so and I wonder if something in the assembler/linker might be playing
> a role in this.
> 
> Tom
> 
> 
> > > For this reason Karl deliberately compiles TL for x86_64-linux on
> > > a reasonably old system.  They perfectly work on newer systems
> > > too.
> > >
> > > I'm also not inclined to install a newer version of Raspbian right
> > > now
> > > either, especially because security updates are still available.
> > > Instead I'm now compiling TeX Live on Raspbian GNU/Linux 10
> > > (buster).
> > >
> > > This takes a lot of time because Raspberries are much slower than
> > > my main machine and because I currently use only one of the four
> > > CPUs. When I instruct Make to use all CPUs the system runs out of
> > > memory and
> > > crashes when it tries to compile four programs at the same time.
> > >
> > > When I succeed I'll put the binaries on my web server and let you
> > > know.
> > >
> > > Regards,
> > >   Reinhard
> > >
> > > --
> > > ------------------------------------------------------------------
> > > Reinhard Kotucha                            Phone: +49-511-3373112
> > > Marschnerstr. 25
> > > D-30167 Hannover                    mailto:reinhard.kotucha at gmx.de
> > > ------------------------------------------------------------------
> > >  
> >
> >