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