How is piCore's build process maintained?

[bertd2]

In this topic, the lack of libpcap support for aarch64 builds is acknowledged, and a workaround provided:

  https://forum.tinycorelinux.net/index.php/topic,26650.msg171686.html#msg171686

What I can't figure out is what would need to happen to get libpcap support added to the piCore aarch64 build. I've found the Github repo at https://github.com/tinycorelinux, but I'm trying to find my way around and can't seem to find the right cue. I'm willing to do the legwork if someone can get me started on where to start searching.

Kudos to the piCore maintainers: I ported all of PiDP11 to a tcz module in an evening, with just libpcap and a weird inconsistency in libtirpc being the speed bumps... It's so cool to see the expensive computer of my college days run from RAM on a Pi3, including the hard disk... Figuring out where the best place to addres the libtirpc issue would best be solved is next on the list, but again I can't figure out where to start pulling the threads.

[Paul_123]

It’s mostly manual.  If there is any package info, it’s in the src folders

http://www.tinycorelinux.net/16.x/aarch64/tcz/src  you can look in older version, as this info only gets updated when significant changes happen.

[Juanito]

Figuring out where the best place to addres the libtirpc issue would best be solved is next on the list, but again I can't figure out where to start pulling the threads.

I'm not sure what your libtirpc issue is, but libtirpc updated in the piCore64-16.x repo.

[bertd2]

Ah, Paul_123 and Juanito, thanks for your replies, I've got a better picture of how it all fits together now!

There is an incompatibility between PiDP11 and PiCore 15.x that appears to originate in libtirpc. In the code that comes with 16.x, the same call is made from libtirpc: in getclnthandle(), getaddrinfo() is called to get the address for the sunrpc service from rpcbind. In /etc/services, the port for sunrpc (111) is listed as "rpcbind" rather than "sunrpc", causing the lookup to fail. I wanted to verify that libtirpc actually uses that name (it does, just checked). As a datapoint, Ubuntu 24.04 has port 111 in its /etc/services are "sunrpc", so there is precedence for continuing to use the old name like libtirpc does.

The "sunrpc" name is hardcoded in libtirpc, so it's not a simple matter of adding a compile to flag to the libtirpc build to use the new name for the rpcbind port.

The easiest fix is to duplicate the two "rpcbind" lines in /etc/services so that "sunrpc" refers to the same port, and the port can be addressed by its old as wel as its new name.