So in general I get the feeling that to add socketCAN support to FPC will require a fairly extensive modification of the base sockets library.
PF_CAN is just a number. In linux sources you can find it defined as AF_CAN, which is defined as 29. So why don't you try that first?
EDIT: I see now that you are looking at sources of candump. It will be much easier if you use simpler example from here:
https://www.beyondlogic.org/example-c-socketcan-code/
True. And in my example I assigned 29 to PF_CAN. The beyondlogic example in C translated to pascal still suffers from the same issue that it's not handled in the socket library. Thank you for that link. It does simplify the code. The candump.c has become more complicated with CAN_FD support which I'm not interested in looking at right now. Especially since it's not supported by the MCP2515 and the BeagleBone internal CAN device nor many of the other existing CANopen modules out there.
I don't really want to add what appears to be an extra layer with TCP if I don't have to. I'll download and compile socketcand to see if it fits in with what I want to do.
BTW, under winsock2.pp 29 is allocated to
AF_TCNPROCESS = 29;
AF_TCNMESSAGE = 30;
AF_ICLFXBM = 31;
AF_MAX = 32;
My goal is to make something that runs on Windows, Pi and BeagleBones and other small modules running Linux. Even LinuxCNC. Not that concerned about Linux Desktop PCs. The PC doesn't have the SPI or embedded CAN device so the CANUSB from Lawicel (or equivalent module with identical protocol) is what I'm currently targeting.