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 _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
