What do I need to put multilib together?

[spork_kitty]

I need 32-bit userland for the Raspberry Pi build of PICO-8. genpi doesn't ship with a 32-bit userland and wasting a USB slot on a separate OS for one executable is a bullshit solution.

Since it doesn't seem to work yet I want to know what I need to do to make it work, WITHOUT a half-assed kludge. My desktop is multilib, why can't my Pi be too?

Edit: PICO-8 doesn't work on aarch64. Tools report that it is linked, it isn't linked, whatever. A 32bit libc and sdl are required at minimum, which will essentially require multilib *anyway*. Which I was told I don't want.

Just delete the thread and forget about it. I'll wait for Lexaloffle to build for aarch64.

[NeddySeagoon]

spork_kitty,

Nobody wants to make arm64 multilib. That's not a Gentoo thing.
On amd64, multilib is/was a kludge to get by while most stuff was 32 bit only.
C and C++ is mostly 64 bit clean now. The only things that need 32 bit are evil binary only packages, or a few rare things that have not been ported to 64 bit.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[spork_kitty]

I'm sorry but I find that to be a poo-poo non-answer, like you're blowing off what I'm asking: the ARM hardware in the RPi3B can support mixed userland, no? It's *possible*. Multilib was attained on other architectures. This means there is a method to get a 64-bit processor to speak its 32-bit variant.

As far as I can tell it comes down to producing a 32-bit compiler to compile the libraries and other things you need to be 32-bit. I asked *how* it's done.

If you're saying it's too much work then I'd like to know why you feel that way. I see great potential in a system that can take any ARM binary you throw at it.

[mDup]

[NeddySeagoon]

spork_kitty,

It can be done for some arm64 CPUs, not all. On arm64 hardware, 32 bit support is optional.
It works on Raspberry Pi, where 64 bit was a nice to have.
It fails on Cavium Thunder, which is a very nice arm64 system but it has no 32 bit support.

Expect to see arm64 moving towards 64 bit only CPUs to minimise the power and silicon areas required.

Like amd64 /multilib/, you need to keep the 32 and 64 bit code separate on disk.
You need both 32 bit and 64 bit toolchains. amd64 cheats here as gcc has the -m64 and -m32 switches and there is only two ABIs to support.

32 bit arm has a whole family of ABIs and CPUs. Its a mess. Do you support them all, or just a small number, like one.
Which one?
They are not interoperable.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[spork_kitty]

Okay, I didn't know how fragmented the archspace was for ARM. I had thought there was aarch64 and armhf. Perhaps those are the only two ABIs on RPis.

This means that 32-bit support on ARM chips is essentially hardware-specific, and the arch didn't start to unify until it hit 64-bit?

If I have that correct then it means supporting all of 32-bit ARM is difficult and the hardware-specific builds are stuck on that hardware and not guaranteed to be workable on another ARM chip.

So I could make a 32-bit Rpi3 toolchain, but it'd only be usable to Rpis?

[NeddySeagoon]

spork_kitty,

You can make an armv6j-hardfloat-linux-gnueabi toolchain and it will work on all hardfloat-linux-gnueabi newer than armv6 systems too.
That has all the 32 bit Pis covered.
You would need another one for softfloat. In arm32 the FPU and some of the extensions are optional, so it gets very messy very quickly.

You can fine tune the output with CFLAGS to suit armv7a and armv7l.

Building all the bits is easy. Putting them together and making them stick is much harder.

In theory, you can make a 32 bit statically linked binary for a 32 bit Pi and execute it on a 64 bit Pi, as long as you have 32 bit support in the kernel.
Does that work?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[spork_kitty]

I'll need to put together a new kernel to test that. PICO-8 does have a statically built binary (in addition to a dynamic one) so maybe a kernel change is all that's needed?

[erm67]

I use a mainline kernel with defconfig and since 32bit compatibility is enabled by default, statically linked 32bit programs work just fine without doing anything particular:

[spork_kitty]

Here's what I'm getting on sakaki's genpi image:

https://i.imgur.com/ivkO2Md.png

Permissions on both executables are 0755 (rwxr-xr-x) and I own them.

[Hu]

May I ask why you posted a screenshot of a terminal, instead of the text of that terminal? I can't quote a screenshot, and it won't stick around long term like your post will.

That looks like the typical failure mode for running a program while its dynamic linker is missing. What is the output of ls -l on the dynamic loader for that file?

[spork_kitty]

I'm posting from my desktop and the XFCE screenshot tool (on the Pi w/attached screen) was the fastest route. When I get around to it I'll install wgetpaste or something.

ls: cannot access '/lib/ld-linux-armhf.so.3': No such file or directory

I noticed `file` issued the same message on both files, too. Does that mean the ./pico8 executable is not, in fact, statically linked?

[GDH-gentoo]

[erm67]

You need a static binary (ELF executable), not a stripped one:

[spork_kitty]

Due to popular demand...

[erm67]

It is funny that ldd say it is not a dynamic executable ... probably a bug.

readelf show it is, the problem probably is this library:

[spork_kitty]

I'm kinda losing interest in this.

I don't care why it doesn't work since I can't fix it and I was told I don't want to build 32-bit.

Easier to forget about it than to sit here guessing at the cause.

PICO-8 simply does not work on aarch64.

[erm67]

[spork_kitty]

Right, proprietary is evil and all, but so far I haven't found another entry-level game IDE that integrates its editor and runtime in one binary, a fun API small enough to fit in my head, and has a community even half as friendly as PICO-8's. Add to that its numerous export options and super simple distribution (literally a PNG file)... It'd be nicer if the source was available, but considering what's gone on socially in the free software world, I can respect zep's choice. Corporations use permissive licensing to build their businesses and it's wrong. As much as I enjoy free software, the atmosphere has changed to one of exploitation, where businesses can and do build on projects written by others and contribute nothing -- financial or otherwise -- back. Giving source freely means giving others an economic advantage over you; you had to spend hours to produce the code; it takes minutes to clone and build. Since not enough people vote with their wallets wrt free software, developers have no choice but to turn to for-profit ventures to make ends meet.

To make my stance clear, proprietary IS evil, but we live in an evil world with perverse incentives, necessitating evil behavior just to eat. It would be nice if the world could have free software authors who are compensated for their work. And by that I mean 90%+ of them, not just the top 1% of them. But, (a) we know that is not going to happen and (b) I digress...

I recently started looking into LOVE2D but its social policy and lack of locally-available docs don't really inspire me.

I think you're right that I'll have to split SD cards up according to purpose. It's a disappointment but the only practical option left to me.

[Hu]

I think in this case, the remark about binary proprietary blobs was because of the technical problems they cause, not a commentary on the larger social/political issues. Here, the technical problems include:

• There is no published blob that works out of the box on your system, and without source, you cannot build a working program locally, even if the source code would actually build cleanly for this environment.
• Debugging the problem is more difficult since we can only inspect the blob, but not the compiler/linker invocations used to create it.
• We cannot easily add debugging statements.
• Modifying the blob to improve compatibility is far less convenient than modifying source code. Some blobs include licensing language prohibiting modification of the blob, so even if we knew how to fix it, it would not be permitted. Most things released with full source code have a license sufficiently permissive that modifications to improve compatibility are permitted.

[erm67]

He also has a second "portable" binary that only depends on libSDL and libc, that would be easier to handle, but still it is a dynamically linked binary and requires that a minimal 32bit environment is installed.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net

[spork_kitty]