> The recommended FPC approach, on the other hand, is a combination of
> "Use functions from the RTL, BaseUnix, or other random packages" and
> "Import the relevant functions yourself", and the documentation is "Hope
> some exists or that adding an fp prefix works".
The baseunix unit was documented from the start and actually adheres better
to manual pages than unit libc (which quite often uses artefacts from old
kernels and not current mechanisms. Even current by 2003-4 standards)
And the fp prefix, while much maligned is at least systematic. No need to
call _write or so.
Yes, it is less complete, but for that it is portable.
> Add to that, sometimes the RTL does have the imports/record translations
> you need, but doesn't bother to expose them publicly.
> Free Pascal has done great things, and I absolutely appreciate all of
> it, but not having a good alternative to Libc.pas or Delphi's new
> Posix.*.pas APIs has definitely been an annoying pain point.
In our previous episode, Michael Van Canneyt said:
> That said, if someone steps up and offers to update Libc for all supported
> architectures, she/he is welcome. But be warned that this will not be easy.
> The structures depend highly on the CPU. Delphi supports only 2 CPUs (64-bit
> and ARM). FPC slightly more...
On 23.03.2017 20:40, Michael Van Canneyt wrote:
> The idea was, and is still today, that you can write applications that
> independent of libc, and talk to the kernel directly.
While this usually is the obvious way to go, there are some Arch and OS
dependent user space things that are hard to perfectly manage in the
fpc-RTL, but are optimizedly provided in the Arch and OS dependent
library versions (e.g. Futex and (maybe) threadvar and "Atomic"
support). I remember that since some time, the Linux Kernel itself
offers "user space system calls" i.e. a "static" library used to do as
well certain user space stuff as system calls wrapped in normal
procedure calls. Astonishingly, last time I checked, Futex has not been
included in that "library".
First off, I’m sorry for implying that the current units are insufficient. I just looked through our code and we’re using far fewer “external ‘c’” definitions than I thought we were. The documentation generally looks good too, so I assume most of trouble was from not being as familiar with Free Pascal’s RTL layout and using search techniques that worked better for Delphi/Kylix than for it. We had to maintain both FPC and Kylix code in parallel for several years too, and that undoubtedly made things more complicated than they would have been otherwise. I’ll keep that bias in mind in the future.
On 3/23/2017 2:40 PM, Michael Van Canneyt wrote:
> No-one has ever offered to maintain a Libc import unit. It was provided
> only as a courtesy to Kylix devs.
That's probably because the Wiki says:
"The libc unit is deprecated, and frozen in time for Kylix compatibility, and won't be ported to other architectures or operating systems."
It also has a long list of other reasons why the entire idea is flawed. We had a rough port to both Linux64 and Darwin32 but never tried to submit those changes back for that very reason.
> That said, if someone steps up and offers to update Libc for all
> supported architectures, she/he is welcome.
This is another instance where you’re (possibly unconsciously) discouraging people from submitting patches. By saying “update ... for all supported architectures”, you’re implying that adding Linux64 or Darwin isn’t worth it unless they also spend time on ARM, Haiku, and uclibc. I certainly understand that from a idealogical point of view, but if someone doesn’t have the time or knowledge to cover everything, it does make it seem like a partial patch wouldn’t be welcome. OTOH, maybe that is intentional, and I can’t say it’s wrong, since it does provide a high barrier to expanding the scope of that unit.
In any case, it’s not relevant for us now. As I said, we recently removed all of our Libc.pas usage.
On 3/23/2017 4:29 PM, Marco van de Voort wrote:
> Could you name the mantis items with improvements/problems ?
No, though I’ll try to submit some for the cases where there could be improvement.
The only thing I can think of that would have been retroactively useful is if Libc.pas had included deprecated declarations with messages saying where the replacement units/methods are.
> We had to maintain both FPC and Kylix code
> in parallel for several years too, and that undoubtedly made things more
> complicated than they would have been otherwise. I?ll keep that bias in
> mind in the future.
> > No-one has ever offered to maintain a Libc import unit. It was provided
> > only as a courtesy to Kylix devs.
> That's probably because the Wiki says:
> "The libc unit is deprecated, and frozen in time for Kylix compatibility,
> and won't be ported to other architectures or operating systems."
It is important to realize that the libc unit was never FPC's primary api.
It was _always_ merely a kylix compatibility unit. Before the current set
the primary api was the "linux" unit, which was later renamed to "unix".
These units already supported *BSD before Kylix even existed.
> It also has a long list of other reasons why the entire idea is flawed.
> We had a rough port to both Linux64 and Darwin32 but never tried to submit
> those changes back for that very reason.
I still think that is a good thing (abandoning unit libc). While
individual calls might be fixable, as a whole it isn't.
If a new effort was made, I'd rather have new libc.so importing units that
were fairly portable to all *nix targets.
> I certainly understand that from a idealogical point of view, but
> if someone doesn?t have the time or knowledge to cover everything, it does
> make it seem like a partial patch wouldn?t be welcome. OTOH, maybe that
> is intentional, and I can?t say it?s wrong, since it does provide a high
> barrier to expanding the scope of that unit.
Yes. Which is why at least I tried to discourage that whole idea.
It is not just ideological, merely practical. By indicating you are
accepting partial patches you risk either committing them before the other
platforms are ready and setting a bad api/precedent, or leaving the patches
to linger in mantis forever.
Better direct the efforts to something better managable.
> The only thing I can think of that would have been retroactively useful is
> if Libc.pas had included deprecated declarations with messages saying
> where the replacement units/methods are.
The libc unit has had that status since 2003-2005. Deprecated and even more
deprecated-with-messages was a much, much later feature (2.4, 2010?). There
had been only the most minimal patches for unit libc (and virtually no
indications of serious usage) for years by then.
I think a better solution would have been to support large parts of the FPC
api on top of Kylix. But when I reacted with comments like that I was
usually met with a reluctance to invest in Kylix at all. So you get a
catch-22 with still supporting kylix but not investing it, not even to
manage its legacy.