Fatal: Can't find unit libc used by unit_nameAfter some searching for this error message, i found this topic (https://forum.lazarus.freepascal.org/index.php?topic=12865.0) and this manual page (https://wiki.lazarus.freepascal.org/libc_unit).Fatal: Can't find unit unixsockets used by unit nameSearching for this error message only yielded a supplementary unixsockets unit, but i'd rather use the one provided by the RTL.How can i use CMSG_LEN, struct msghdr, etc. with FreePascal?Something like this (https://github.com/doublecmd/doublecmd/blob/master/src/rpc/sys/unix/ulocalsockets.pas).
Why would you want a unit named linux sockets?:o What...? Seriously...what? Who wanted a unit named linux sockets? I explicitly wrote unixsockets several times. My post did not even contain the word "Linux". I have no idea what are you talking about.
The sockets unit is pure berkely sockets, so unix sockets...
Their structures should also have equivalents in fcl-net.Which are...?
Maybe you want the translated syntax to mimic the C code simply too close and so you would want to work with code that is deprecated.I know. I've even linked in the very same manual page what you did...
Any code that requires the libc unit is deprecated, afaik, not the libc library.
This may help:
https://wiki.freepascal.org/libc_unit
That also describes you should use sockets not unixsockets.sockets has already been pulled in (i just forgot to mention it), but it did not provide CMSG_LEN and the rest.
In general it will help you port code in a more sane way,
Thank you, but this is also just a supplementary unixsockets unit, just like the one (https://lists.freepascal.org/pipermail/fpc-pascal/2014-June/042244.html) made by md (https://forum.lazarus.freepascal.org/index.php?action=profile;u=55475) and what i use now. I'd like to stick to the RTL. Or do you mean, it is not possible to do it with unixsockets and that one has to provide those functions and structures by hand?QuoteHow can i use CMSG_LEN, struct msghdr, etc. with FreePascal?Something like this (https://github.com/doublecmd/doublecmd/blob/master/src/rpc/sys/unix/ulocalsockets.pas).
You say, it should be compiled to a PPU?Yes. It is a standard practice of binary distro.
I thought FreePascal automatically does thatIt can do it. But only if unit in the unit search paths.
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling unixsockets.pp
unixsockets.pp(12,2) Warning: Illegal compiler directive "$UNIXSOCKETSH"
unixsockets.pp(16,2) Warning: Illegal compiler directive "$UNIXSOCKETS"
19 lines compiled, 0.0 sec
2 warning(s) issuedThe PPU was created, but i guess it is erroneous. Or not? What flags i should provide?
rtl-extra\src\linux\unixsockets.incin the include files search paths.
rtl-extra\src\linux\unixsocketsh.inc
unixsockets.pp(12,2) Fatal: Cannot open include file "$unixsocketsh.inc"The file does exist, i've checked it.
-Fi/usr/share/fpcsrc/3.2.2/packages/rtl-extra/src/linuxshould work.
unixsockets.inc(12,12) Error: Identifier not found "__cmsg_nxthdr"
unixsockets.pp(20) Fatal: There were 1 errors compiling module, stoppingThis is caused by rtl-extra/src/linux/unixsockets.inc:12:unixsocketsh.inc(32,12) Error: Forward declaration not solved "CMSG_DATA(Pcmsghdr):^Byte;"Which is caused, that rtl-extra/src/linux/unixsocketsh.inc:32 says:But, looks like this unit a totally broken. I don't know why it is included in the FPC distro at all.It should be broken, must be broken otherwise and marked as deprecated, because it is deprecated and not maintained. It's presence is unwarranted and it should be removed to prevent people using it.
I told you so, use sockets.If by sockets, you mean unit sockets, it was pulled in for other types, but did not provide CMSG_LEN and the rest.
I told you so, use sockets.If by sockets, you mean unit sockets, it was pulled in for other types, but did not provide CMSG_LEN and the rest.
Mark, the structures are elsewhere in the basic unix units, but may have slightly different names. After all these structures are needed for sockets.
I maintain what I stated and I still haven't seen anything that warrants NOT to mark that unit as deprecated.
It should be broken, must be broken otherwise and marked as deprecated
It should be broken, must be broken otherwise and marked as deprecated
The libc unit (https://www.freepascal.org/daily/packages/libc/libc/index.html) are deprecated, unixsockets are not deprecated. But it has bugs which we discussed above.
Macros, particularly function-like macros that take one or more parameters, are very poorly served by FPC.They were there, although as functions. But that too works for me.
However I have to ask here: what are you actually trying to do?I was porting a C unit which transmits/receives live socket descriptors through datagram sockets. (To be able to pass an opened socket to another process.)
We've already fixed the bugs, or have we? You've fixed the unit, i've fixed the includes and now both unixsockets and my unit compile.It should be broken, must be broken otherwise and marked as deprecated
The libc unit (https://www.freepascal.org/daily/packages/libc/libc/index.html) are deprecated, unixsockets are not deprecated. But it has bugs which we discussed above.
They were there, although as functions. But that too works for me.
I was porting a C unit which transmits/receives live socket descriptors through datagram sockets. (To be able to pass an opened socket to another process.)
Should i make a patch?
Yes, but functions aren't macros.I know, but in this case they were usable as a drop-in replacement.
OK, fpSendTo() works fine with datagrams. For strictly local use consider unix-domain sockets rather than UDP.But i did use unix domain sockets; they can be datagram ones and AFAIK to pass an FD to another process, one has to use datagram sockets. (Fixme?)
Not necessarily, but you should certainly raise a bug report for those malformed include directives (possibly referencing anything incoherent that Thaddy attempted).Okay. Where should i do that? On SourceForge, or GitLab, or GitHub, or here in a specific zone/group?
I know, but in this case they were usable as a drop-in replacement.
But i did use unix domain sockets; they can be datagram ones and AFAIK to pass an FD to another process, one has to use datagram sockets. (Fixme?)
Okay. Where should i do that? On SourceForge, or GitLab, or GitHub, or here in a specific zone/group?
Edit: Okay, i found, that it is GitLab. (https://wiki.freepascal.org/How_do_I_create_a_bug_report)
Edit: But i cannot log in to my GitLab account, because that stupid CloudFlare botchecker does not let me in. From Chromium, it simply gives back the checkbox each time i check in and from Pale Moon it simply never gives the checkbox. Great...
I don't entirely understand what you're doing with FDs, and it sounds- at the minimum- to be highly OS-specific (i.e. even if it works on Linux it might not work on Berkeley derivatives).
But if you can do something with unix domain sockets, then I see no reason why UDP wouldn't work... until somebody tried to use it to send info between different hosts, or potentially different namespaces (i.e. containers etc.).UDP does work, these are UDP unix domain sockets. This is for incoming FD-s:
UDP does work, these are UDP unix domain sockets. This is for incoming FD-s:
Note that you've got PF_something (program family) and then an indication of whether something's a datagram or a stream.I think you meant protocol family.
SOCK_DGRAM usually means UDP (on PF_INET) or unix-domain sockets (on PF_UNIX), I'm not sure that SOCK_STREAM on PF_UNIX is a valid comobination.It is not? This SO-topic says, it is (https://stackoverflow.com/questions/13953912/difference-between-unix-domain-stream-and-datagram-sockets):
The main difference is that one is connection based (STREAM) and the other is connection-less (DGRAM) - the difference between stream and packet oriented communication is usually much less important.Of course, he might be wrong, i am not an expert on sockets.
With SOCK_STREAM you still get all the connection handling, i.e. listen/accept and you can tell if a connection is closed by the other side.
If you're using PF_INET then you also need AF_INET to specify an IP address...Yep, i know, but this was IPC, not network.
...and that you might need to remove the names from the filesystem when your program finishes, or take special precautions when it starts and finds that the name already exists.Yes, i did: i do fpunlink(name) before the fpsocket call.
I think you meant protocol family.
Edit: Forgot to thank you for your pipe code; thanks. :)
Apropos _DGRAM vs _STREAM: more to the point, unix(7) says that both are acceptable, albeit with a couple of protocol caveats... and I'd need to think hard about some of the things I've used it for. However in the current case I thing it's best to focus on the "dgram vs stream" rather than "connected vs unconnected" aspect, since if you're passing block data around (i.e. FDs) you really do need datagrams.So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.
So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.
No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.Probably, or at the very least blocks getting merged arbitrarily. That's one reason why, when it was still unclear what you were doing, I threw SCTP into the mix: it's somewhat (!) more complex ("designed by committee" is the phrase that springs to mind), but offers reliable block delivery over a network (provided that the in-path routers etc. support it, which is rare).
I've realised that I missed out some very juicy stuff from the example code I C&Ped yesterday, and am about to go back and extend it.I think you should make a unit of it and commit it into the FPC RTL, or publish it in your repo.
No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.So, that's why SOCK_STREAM did not worked: no blocks, just a stream of bytes without any particular meaning. Thanks, for pointing out.Probably, or at the very least blocks getting merged arbitrarily. That's one reason why, when it was still unclear what you were doing, I threw SCTP into the mix: it's somewhat (!) more complex ("designed by committee" is the phrase that springs to mind), but offers reliable block delivery over a network (provided that the in-path routers etc. support it, which is rare).
It's more widespread than you might realize, cause it's one of the core protocols used by WebRTC (https://en.wikipedia.org/wiki/WebRTC) which is supported by all modern browsers and other applications that use WebRTC to provide peer-to-peer communication.
No, i've never worked with SCTP. As a matter of fact, i did not even ever heard of it, but after a quick search, i think i am not alone with that: it is not very widespread.The Stream Control Transmission Protocol (SCTP) was originally designed by the Signaling Transport (SIGTRAN) group of IETF for Signalling System 7 (SS7) transport over IP-based networks. It is a reliable transport protocol operating on top of an unreliable connectionless service, such as IP.
It's more widespread than you might realize, cause it's one of the core protocols used by WebRTC (https://en.wikipedia.org/wiki/WebRTC) which is supported by all modern browsers and other applications that use WebRTC to provide peer-to-peer communication.
In fairness, /can/ be used by would be a better way of putting it. It works peer-to-peer on a local LAN, it works over a tunnel provided that the relevant ISPs are competent ** , but IME is not at all well-supported across commodity routers and firewalls.
It's definitely got its good points, but an "SCTP lite" which offered reliable datagram transmission (i.e. like UD sockets but between systems) would go down well.