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

[Marco van de Voort]

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.