In our previous episode, Henry Vermaak said: > > The cure is ten times more difficult than the problem. (namely that the > > That seems quite clear. > > > Libc breaks often, but I'm sure that a native lib will break much more > > I certainly haven't experienced this libc that breaks often.
Keep in mind that that is defined in the context of cross-distro compatibility of the binary interface. This because we only have one source, and don't automatically adapt to differences. So if only one distro e.g. starts increasing time_t to 64-bit, it is considered broken (we can't have a binary distro that works everywhere) till all distros have adopted time_t to 64-bit. Gentoo is usually the distro that is first with such changes btw. Only one such change in 2 years, but that takes its time to ripple through to all distros can already cause effective "breakage" half of the time. Besides that there is the reference distribution problem. This goes even a step further, and not only requires that something from FPC source, linked on target is working on all distros, but requires that the reference FPC release (the .tgz on linux, nearly all, binaries are libc free atm) works on all distros, and can be used as a base for bootstrapping. This breaks as soon as a binary linked on one distro doesn't work on the other. Even renaming a library breaks this, since it will not exist on the other platform. > Does that mean that our linux threading will also break often because we > rely on libc for that? Again, I haven't seen this, either. Its not the threading, but the fact that if _something_ that you use from libc, or the link process _TO_ libc leads to an incompatible binary. As far as threading goes, post NTPL (which hurt pretty bad btw), I can vaguely remember some problems related to sem_timedwait. _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
