[fpc-pascal]sigpending broken on OpenBSD?

[Marco van de Voort]

> marcov at stack.nl (Marco van de Voort) wrote:
> 
> > - submit a working program that shows the bug.
> > - describe compiler options, and possible other conditions that trigger
> >   the bug.
> 
> I was just curious... I've dropped using sigpending/sigprocmask now have
> just switch to a global variable and a signal handler.  Good enough until
> the sigset stuff is finalized... I've got a couple programs compiling/
> running on FreeBSD, OpenBSD, NetBSD, and Linux and am currently banging
> my head against QNX.  (I run my BBS on all five OSs)

The problem with OpenBSD seems to be that it is meant for making
routers/firewalls using the base system. They seem less interested in
applications. 

Btw, you are the _first_ feedback on the OpenBSD port :-)
 
> The fun part looks like it's going to be getting a Linux unit (Should that
> perhaps be renamed NIX or something?), ncurses, oCrt, etc all working on
> the QNX system... the other four seemed to be no real problem.  (I'm not
> even really sure what the Linux unit is built from)

This is all because the first non-linux Unix port, FreeBSD, dates
from somewhere between 1.0 and 1.0.2 (1.0 was may 2000 or so).

The early FreeBSD rtl was a mere patch on the linux rtl. When it started to
stabilize, we already decided to not do any large new rearrangements in
the 1.0.x branch.

In the 1.1 development branch, we renamed linux to "unix", but we are
currently changing this even some more:

- The three BSDs have pretty much a "shared" RTL. Maybe the 4th BSD
   will be added (Darwin), but this depends on how big the overlap is,
   otherwise it gets its own copy of the BSD rtl.
- all real posix/unix functions move to new unit baseunix and
	- get renamed to "fp<name under C>", 
     	- are declared using unix typing (off_t, dev_t ino_t etc), 
        - overloaded variants of the base calls move too.
	- In the future, a RTL recompile with a certain define should base
	  all calls on libc (needed for Darwin)
- Some derivative functions (like shell()) will remain in unix in a cleaned
    up way. The exact division between unit Unix and Baseunix hasn't
    been decided yet.
- Processor specific functions go to a separate unit (the x86 port stuff
  ioperm and iopl)
- Real OS specific stuff, if any (like the "sysinfo" call) moves to the
   respective platform dependant unit. (linux, openbsd, netbsd etc) Maybe
   there will be a "bsd" unit too.

Some of these things (renaming, unix typing etc) should have done directly
when FreeBSD was added, but that's in retrospect.

---
This means that 1.1.x will probably break all "linux" unit using programs,
and it can only partially be resolved by renaming "uses" clauses and 
even functions (there is still the typing)

However there was no way to avoid this, since the number of platforms
exploded, and even new architectures have been added. We now have
(linux,netbsd,openbsd) on (i386,m68k,powerpc and in the future sparc),
which is potentially already a 3x3 or 3x4 matrix in itself.

I assume that when the Sparc port becomes operational, Solaris will also
get revived.

Ifdef'ing half of linux to 10-20 levels deep is simply not an option, so
we decided to redesign it entirely before the next major version of FPC.
(which will be 3-4 years after 1.0 anyway, so nobody will accuse us of
rushing :-)