[fpc-devel] Threading support and C library under Linux/Unix

[Marco van de Voort]

In our previous episode, Hans-Peter Diettrich said:
> > 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.

Well, since this is about a maintenance problem, it would only solve it if
the maintenance of the C compiler would be lower than the maintenance of
fixing the headers/RTL.....    Which I doubt strongly, even if we forget
about the gigantic initial costs (making a production C compiler)

If a real systematic problem here would ever appear, I would go more in the
direction of a configure like hack. Characterising the system by compiling
small C programs. 

> > 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.

I think I don't entirely understand what problem this paragraph is about. Yes, we have two
errnos now, but not doing that means that you essentially have to create a
configure like layer. (since this is not even automagical for C programs)

In the light of that, I have no problem with the current solution.