Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
What do I need to put multilib together?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM
View previous topic :: View next topic  
Author Message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Tue Jan 14, 2020 1:44 am    Post subject: What do I need to put multilib together? Reply with quote

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.


Last edited by spork_kitty on Tue Jan 28, 2020 10:37 pm; edited 1 time in total
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 47055
Location: 56N 3W

PostPosted: Tue Jan 14, 2020 12:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Sun Jan 19, 2020 7:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mDup
Apprentice
Apprentice


Joined: 14 Apr 2006
Posts: 202

PostPosted: Sun Jan 19, 2020 7:20 pm    Post subject: Reply with quote

spork_kitty wrote:
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.


perhaps one can compare amd64 and arm64 portage files an adjust arm64 ones.

but the current official arm64 files do not support multilib, there is no equivalent of abi_x86_32 use for arm there.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 47055
Location: 56N 3W

PostPosted: Sun Jan 19, 2020 7:24 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Sun Jan 19, 2020 9:03 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 47055
Location: 56N 3W

PostPosted: Sun Jan 19, 2020 10:16 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Sun Jan 19, 2020 11:23 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Mon Jan 20, 2020 6:53 pm    Post subject: Reply with quote

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:

Code:
erm67 ~/ffmpeg-git-20200114-armhf-static # file ffmpeg
ffmpeg: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=066ab73ba54d4303c53fffdf74821ef6174d663d, stripped
erm67 ~/ffmpeg-git-20200114-armhf-static # ./ffmpeg
ffmpeg version N-51386-gb55c6b8c40-static https://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: --enable-gpl --enable-version3 --enable-static --disable-debug --disable-ffplay --disable-indev=sndio --disable-outdev=sndio --cc=gcc-6 --enable-fontconfig --enable-frei0r --enable-gnutls --enable-gmp --enable-libgme --enable-gray --enable-libfribidi --enable-libass --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librubberband --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libvorbis --enable-libopus --enable-libtheora --enable-libvidstab --enable-libvo-amrwbenc --enable-libvpx --enable-libwebp --enable-libx264 --enable-libxml2 --enable-libxvid --enable-libzimg
  libavutil      56. 38.100 / 56. 38.100
  libavcodec     58. 65.103 / 58. 65.103
  libavformat    58. 35.102 / 58. 35.102
  libavdevice    58.  9.103 / 58.  9.103
  libavfilter     7. 71.100 /  7. 71.100
  libswscale      5.  6.100 /  5.  6.100
  libswresample   3.  6.100 /  3.  6.100
  libpostproc    55.  6.100 / 55.  6.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'
erm67 ~/ffmpeg-git-20200114-armhf-static # uname -a
Linux erm67 5.4.9-dirty #6 SMP PREEMPT Thu Jan 9 11:00:54 CET 2020 aarch64 GNU/Linux
erm67 ~/ffmpeg-git-20200114-armhf-static # zgrep 32BIT /proc/config.gz
CONFIG_COMPAT_32BIT_TIME=y

_________________
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
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Thu Jan 23, 2020 1:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16472

PostPosted: Thu Jan 23, 2020 2:09 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Thu Jan 23, 2020 2:34 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
GDH-gentoo
Guru
Guru


Joined: 20 Jul 2019
Posts: 599
Location: South America

PostPosted: Thu Jan 23, 2020 1:28 pm    Post subject: Reply with quote

spork_kitty wrote:
Does that mean the ./pico8 executable is not, in fact, statically linked?
Yeah, both pico8 and pico8_dyn are dynamically linked. The only difference is that the former is stripped (has symbols removed), and the latter isn't. ld-linux-armhf.so.3 is one of the standard names of GNU libc's dynamic linker for 32-bit ARM.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Thu Jan 23, 2020 4:56 pm    Post subject: Reply with quote

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

Code:

erm67 ~/ffmpeg-git-20200119-armhf-static # readelf -l ffmpeg

Elf file type is EXEC (Executable file)
Entry point 0x861d5
There are 7 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x1a5b830 0x01a6b830 0x01a6b830 0x07ca8 0x07ca8 R   0x4
  LOAD           0x000000 0x00010000 0x00010000 0x1a634dc 0x1a634dc R E 0x10000
  LOAD           0x1a63a88 0x01a83a88 0x01a83a88 0xef580 0xc3c00c RW  0x10000
  NOTE           0x000114 0x00010114 0x00010114 0x00044 0x00044 R   0x4
  TLS            0x1a63a88 0x01a83a88 0x01a83a88 0x00038 0x00094 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x1a63a88 0x01a83a88 0x01a83a88 0xb7578 0xb7578 R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx
   01     .note.ABI-tag .note.gnu.build-id .rel.dyn .init .iplt .text __libc_freeres_fn __libc_thread_freeres_fn .fini .rodata .stapsdt.base __libc_subfreeres __libc_IO_vtables __libc_atexit __libc_thread_subfreeres .ARM.extab .ARM.exidx .eh_frame
   02     .tdata .init_array .fini_array .jcr .data.rel.ro .got .data .bss __libc_freeres_ptrs
   03     .note.ABI-tag .note.gnu.build-id
   04     .tdata .tbss
   05     
   06     .tdata .init_array .fini_array .jcr .data.rel.ro
erm67 ~/ffmpeg-git-20200119-armhf-static # readelf -d ffmpeg

There is no dynamic section in this file.
erm67 ~/ffmpeg-git-20200119-armhf-static # ldd ffmpeg
   not a dynamic executable


_________________
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
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Tue Jan 28, 2020 1:24 am    Post subject: Reply with quote

Due to popular demand...

Code:

$ ls -l
total 16600
-rwxrwxr-x 1 me me      442 Jul 31 09:52 lexaloffle-pico8.png
-rwxrwxr-x 1 me me     4870 Jul 31 09:52 license.txt
-rwxrwxr-x 1 me me   100816 Jul 31 09:52 pico-8.txt
-rwxr-xr-x 1 me me  1811380 Jul 31 09:52 pico8
-rw-rw-r-- 1 me me 14086382 Jul 31 09:52 pico8.dat
-rwxr-xr-x 1 me me   975700 Jul 31 09:52 pico8_dyn

$ file ./pico8
./pico8: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=e7450cc8779399043fc0aacfadd306b3be65bd93, stripped

$ file ./pico8_dyn
./pico8_dyn: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=cca775896c105072f788adc5a2257bc0ea34497b, not stripped

$ ./pico8
bash: ./pico8: No such file or directory

$ readelf -d ./pico8

Dynamic section at offset 0x1b5ee0 contains 31 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [librt.so.1]
 0x00000001 (NEEDED)                     Shared library: [libbcm_host.so]
 0x00000001 (NEEDED)                     Shared library: [libwiringPi.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [/usr/local/lib]
 0x0000000c (INIT)                       0x12f44
 0x0000000d (FINI)                       0x1869b0
 0x00000019 (INIT_ARRAY)                 0x1d5bd4
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0x1d5bd8
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x6ffffef5 (GNU_HASH)                   0x101b4
 0x00000005 (STRTAB)                     0x11a14
 0x00000006 (SYMTAB)                     0x109d4
 0x0000000a (STRSZ)                      2751 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x1d6000
 0x00000002 (PLTRELSZ)                   1920 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x127c4
 0x00000011 (REL)                        0x1279c
 0x00000012 (RELSZ)                      40 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x126dc
 0x6fffffff (VERNEEDNUM)                 5
 0x6ffffff0 (VERSYM)                     0x124d4
 0x00000000 (NULL)                       0x0

$ readelf -d ./pico8_dyn

Dynamic section at offset 0xcff00 contains 27 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libSDL2-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000001d (RUNPATH)                    Library runpath: [/usr/local/lib]
 0x0000000c (INIT)                       0x128cc
 0x0000000d (FINI)                       0xc31f4
 0x00000019 (INIT_ARRAY)                 0xefef4
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)
 0x0000001a (FINI_ARRAY)                 0xefef8
 0x0000001c (FINI_ARRAYSZ)               4 (bytes)
 0x6ffffef5 (GNU_HASH)                   0x101b4
 0x00000005 (STRTAB)                     0x11640
 0x00000006 (SYMTAB)                     0x10910
 0x0000000a (STRSZ)                      2668 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0xf0000
 0x00000002 (PLTRELSZ)                   1544 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x122c4
 0x00000011 (REL)                        0x122a4
 0x00000012 (RELSZ)                      32 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x6ffffffe (VERNEED)                    0x12254
 0x6fffffff (VERNEEDNUM)                 2
 0x6ffffff0 (VERSYM)                     0x120ac
 0x00000000 (NULL)                       0x0

$ readelf -l ./pico8

Elf file type is EXEC (Executable file)
Entry point 0x13f18
There are 9 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x1b4d60 0x001c4d60 0x001c4d60 0x00008 0x00008 R   0x4
  PHDR           0x000034 0x00010034 0x00010034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x00010154 0x00010154 0x00019 0x00019 R   0x1
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
  LOAD           0x000000 0x00010000 0x00010000 0x1b4d6c 0x1b4d6c R E 0x10000
  LOAD           0x1b5bd4 0x001d5bd4 0x001d5bd4 0x041ed 0x510334 RW  0x10000
  DYNAMIC        0x1b5ee0 0x001d5ee0 0x001d5ee0 0x00120 0x00120 RW  0x4
  NOTE           0x000170 0x00010170 0x00010170 0x00044 0x00044 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x1b5bd4 0x001d5bd4 0x001d5bd4 0x0042c 0x0042c R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx
   01     
   02     .interp
   03     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .ARM.exidx .eh_frame
   04     .init_array .fini_array .jcr .data.rel.ro .dynamic .got .data .bss
   05     .dynamic
   06     .note.ABI-tag .note.gnu.build-id
   07     
   08     .init_array .fini_array .jcr .data.rel.ro .dynamic

$ readelf -l ./pico8_dyn

Elf file type is EXEC (Executable file)
Entry point 0x13668
There are 9 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX          0x0cf32c 0x000df32c 0x000df32c 0x00008 0x00008 R   0x4
  PHDR           0x000034 0x00010034 0x00010034 0x00120 0x00120 R E 0x4
  INTERP         0x000154 0x00010154 0x00010154 0x00019 0x00019 R   0x1
      [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
  LOAD           0x000000 0x00010000 0x00010000 0xcf338 0xcf338 R E 0x10000
  LOAD           0x0cfef4 0x000efef4 0x000efef4 0x00c76 0x506ffc RW  0x10000
  DYNAMIC        0x0cff00 0x000eff00 0x000eff00 0x00100 0x00100 RW  0x4
  NOTE           0x000170 0x00010170 0x00010170 0x00044 0x00044 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10
  GNU_RELRO      0x0cfef4 0x000efef4 0x000efef4 0x0010c 0x0010c R   0x1

 Section to Segment mapping:
  Segment Sections...
   00     .ARM.exidx
   01     
   02     .interp
   03     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .ARM.exidx .eh_frame
   04     .init_array .fini_array .jcr .dynamic .got .data .bss
   05     .dynamic
   06     .note.ABI-tag .note.gnu.build-id
   07     
   08     .init_array .fini_array .jcr .dynamic

$ ldd ./pico8
   not a dynamic executable

$ ldd ./pico8_dyn
   not a dynamic executable

Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Tue Jan 28, 2020 8:52 pm    Post subject: Reply with quote

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:

Code:

0x00000001 (NEEDED)                     Shared library: [libbcm_host.so]


a binary proprietary blob that comes with your raspy firmware, you need to install the required libraries in /usr/local/lib and the program interpreter (/lib/ld-linux-armhf.so.3) of course.

Wait pico8_dyn requires a lot less libraries, I mean it's only libc and libSDL, probably worth a try.

Code:
 0x00000001 (NEEDED)                     Shared library: [libSDL2-2.0.so.0]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000001d (RUNPATH)                    Library runpath: [/usr/local/lib]

_________________
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
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Tue Jan 28, 2020 9:00 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Tue Jan 28, 2020 11:51 pm    Post subject: Reply with quote

spork_kitty wrote:
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.

Not a surprise being a 32bit program
That's the problem with binary proprietary blobs .... a few opensource implementations of openGL for ARM boards are coming out so the situation might be better in the near future.
You can always install a minimal 32 bit system of a different binary distro.
_________________
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
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Wed Jan 29, 2020 12:04 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 16472

PostPosted: Wed Jan 29, 2020 3:15 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
erm67
l33t
l33t


Joined: 01 Nov 2005
Posts: 647
Location: EU

PostPosted: Wed Jan 29, 2020 1:31 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
spork_kitty
Tux's lil' helper
Tux's lil' helper


Joined: 05 Jul 2019
Posts: 124

PostPosted: Thu Jan 30, 2020 12:02 am    Post subject: Reply with quote

Hu wrote:
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.


I thought those were all a given and not worth mentioning since, afaict, we all understand those things. I would be surprised to meet a Gentoo user who did not understand the perils of proprietary software. By the time someone makes their way to a source-based distro, they've learned enough about the culture difference and the difficulty in getting proprietary things to work on anything not named Windows.

Given that, I can only guess it was mentioned because someone felt that I didn't know those things. I have no words.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo on ARM All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum