In our previous episode, Henry Vermaak said: > > Yes. And 99% of the thread using programs also use other C libs that use > > libc anyway (*) > > So, to answer your question above about why we need a native one: so > we can do away with the libc dependency.
In 0.1% of the programs. The rest doesn't need libc, or needs libc because of compatibility with other systems. > > As Jonas explained, two thread systems in one binary is almost certain not > > workable. > > Yes, but you wouldn't use the native one when you are linking to libc, > you'll just use pthreads like you do now. I know, but the point is that is the most common case. The case that you actually use a native one would be extremely rare. > > But does it really warrant making a complex lib for that? And for which > > I just link to libc myself, since I've never seen a system without > one, but this whole thread was in response to Michael who complained > that thread support pulls in libc. So this explored an alternative > solution. The cure is ten times more difficult than the problem. (namely that the stock FPC distribution must be cross-distro compatible to allow for bootstrapping and basic usage). Libc breaks often, but I'm sure that a native lib will break much more often. And linux distros merge in emergency libc fixes, but they are often not so fast in propagating patches and new versions of FPC. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
