Marco van de Voort wrote (by private mail, but I suppose it's ok to quote here):
: frank@pascal.gnu.de gave routing errors. Retrying with older address.
BTW, this mail domain moved to a new server recently. Sorry for any problems (also to others here who may have tried to reach me), I hope it's only temporary, and frank@g-n-u.de should work.
: I noted that Rick E. tried to make a point with the libc unit of fpc, : but his reasoning is flawed: ("c library revisited thread") : : FPC only supports the libc unit for kylix compability only and only on : linux/i386 distro's supported by kylix, and a best effort approach for the : others linux/i386 distro's. (this because linux glibc is a very instable : interface to follow with any release frequency that is larger than a few : months). : : His ease of use argument is also bogus, since everything is always easier if : you don't have limitations or portability concerns. : : We do offer a limited selection of Unix calls though, but these are targeted : for specific Unix use, and in no way a substitute for the general calls in : e.g. an unit sysutils. They are prototyped roughly as the C calls, but : with "fp" prefixed, so manual pages still apply.
This probably explains what Rick was wondering about. If even glibc interfaces changes frequently (I suppose so, I'm not following them closely myself), other system's libcs are vastly different ...
So the only way to get a portable libc access (without huge, and constant, rewriting) AFAICS would be either to have a 100% automatic translator that handles everything that occurs in some libc headers (which is likely to be all of standard C + extensions, via macros and inline functions), or to write wrappers in C that use the libc routines in the C way (thus being able to include headers as designed) and provide a well-defined C/Pascal interface. That's basically what we do in the RTS for a subset of libc (sometimes providing a bare-bones interfaces, sometimes higher-level).
As I wrote the other day, automatic translation for most other C libraries is probably a whole lot easier (as glibc headers contain some of the most complicated macros I've seen so far in external headers, apart from the Linux kernel headers) ...
Frank