[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