On 22 June 2010 16:15, Marco van de Voort <[email protected]> wrote: > 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.
Thanks for the explanation, it all makes a bit more sense, now! Henry _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
