Re: Fwd: Re: fpc op Debian kfreebsd-amd64
In our previous episode, Robert Millan said:
> > * Where is the startup code (csu aka CRT* files) coming from? Are they
> > specific to kfreebsd, similar to linux or to freeBSD?
>
> I forgot if it's GCC or Glibc. ISTR it comes from a file called
> "crtstuff.c" which is built a few times with different flags. Same as
> GNU/Linux in any case.
Then the Linux version of those files in FPC should work.
> > * Some libraries on linux are build into the libc on freeBSD and vice
> > versa. My guess is that kfreebsd follows the "linux" way.
>
> I don't understand this question. Can you ellaborate?
Libintl is in the glibc binary iirc, but not in freebsd libc. Libdl
functions are in libc under FreeBSD.
But the pattern of your answers is "Linux, linux, linux", so basically I
think we simply take the linux port, and see what problems emerge.
> > * Where is libphtreads coming from? For fpc: PThreads has a big userland
> > interface, but is probably kernel specific.
>
> Glibc. It is currently based on NPTL.
NTPL is afaik both the revised kernel interface (with other scheduable
entities than processes) and the lib. But I assume that the NPTL the lib can
use the same kind of stuff in FreeBSD(KSE)
Anyway, that is just naming, the point is the pthreads library being Linux
compatible, which is enough for FPC. Threads is not one of the things
abstracted on kernel level in FPC, so that is not a problem.
Then simply compiling a Linux FPC distribution with direct kernel syscall
disabled (OPT=-DFPC_USE_LIBC) should go a long way. Maybe some minor
fallout in cases where kernel and libc structures differ. (like iirc fdset
and sigset_t). Most of them should already be done though.
Another possible problem spot is direct IOCTLs, unless (g)libc
also changes those to FreeBSD appropiate values.
(background:
Historically FPC has relied on syscalls to avoid glibc versioning and to
avoid porting to each distribution separately. (since it can't process C
(and -headers), it is essentially invariant and any difference must be
hand-done).
In 2003-2004 a more libc oriented port was done to have an alternative in case of
emergency. A problem there is for Linux differing kernel and libc
structures. (in FreeBSD maintaining the libc port requires near zero effort)
The Darwin port and some minor targets were based on it, but
production versions of the linux and *BSD ports remain syscall.
The startup code is modified because since the FPC rtl can work both
with and without libc, it is seeded with "raw" data. (unprocessed
environment etc). Also the frame pointer (EBP/RBP) needs to be nilled
because of Pascal's nested procedure support, and exceptions in the FPU mask
enabled.
Reply to: