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. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
