[fpc-devel] Threading support and C library under Linux/Unix
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Wed Jun 23 10:41:21 CEST 2010
Marco van de Voort schrieb:
> The problem is not the programming (since a dedicated person could probably
> start with a translated glibc in a good month), but the continuous
> maintenance (for every distribution separately, since they could use
> different kernels, options etc) , and interoperability with C code would be
> killing.
The Kylix-like addition of an C compiler would help to solve such
issues, that arise from the use of *any* C code with FPC.
An integration of such an compiler (or front-end) into FPC could be
based on my ToPas project, that already parses all C syntax and allows
to translate it into OPL, as far as that language allows for. It should
not be so hard to add the few missing syntax constructs (anonymous
unions, bitfields...) to the FPC compiler.
> This is all more trouble than interface glibc, even longterm. FPC already
> supports this (FPC_USE_LIBC) but it is not maintained/used much for
> Linux/FreeBSD. Because Darwin and Solaris use it, it is not totally outdated
> though.
It may be a bit harder to unify the libc procedures, so that their use
does not duplicate already existing FPC library code, resulting in
confusion like with the errno/cerrno variables. This could be done by a
set of recognized platform-(in)dependent procedures, so that the basic
platform-specific procedures are translated from the (libc...) source
code, while the platform-independent procedures are replaced by the
according FPC implementation.
A solution may be platform-specific header files, that #define macros
for the compatible procedures, redirecting all calls to the existing FPC
library procedures. The then obsolete implementations in the C sources
can be ignored by the compiler, or can be removed by the linker.
DoDi
More information about the fpc-devel
mailing list