[fpc-devel] libc translations

[Marco van de Voort]

> On Sun, 10 Aug 2008, Boian Mitov wrote:
> On the other hand, Kylix based itself on GNU Libc entirely. 
> For compatibility reasons, we have created a similar unit as 
> Kylix had. This unit can be used, but only on i386 and on
> systems that use GNU libc (Linux, in casu), because the 
> record and type definitions it contains are i386 and GNU Libc specific.

Note the problem was less that Kylix based itself on libc, but more the fact
that they stuffed anything they could find into unit libc without any
discrimination:

- linuxisms
- glibcisms
- Libraries that are in fact external, but linked into the glibc library
(but not part of the actualy glibc distribution). Here I mean stuff like
iconv.
- kernel version dependant stuff
- x86 specific issues
- other system libraries like libdl.
 
> You have therefor 2 options:
> - Continue with using Libc, and provide patches that keep it  up to date.

No. Patches to unit libc should be limited to fixes to the Kylix compability
of unit libc, and fixes needed to keep Kylix using code running with
modern kernels.

If there we are serious in creating own versions of libc functionality as
pure headers in the RTL, we could have clinux and cunix for those.
 
> - Implement the functionality that you need in a Posix like way, and make
>   sure it works accros processor architectures and operating systems.
> 
> Naturally, we prefer the latter - as explained by Daniel - but if you 
> want to do the former (which is most likely less work): no problems, 
> we accept patches.

Not for unit libc. New functionality has no place there. In 2.3.1 there is a
formal "deprecated" in that unit even, and then you shouldn't add new
functionality in it. Create a new package, clinux whatever (if it is linux
specific), but _NOT_ unit libc.